Path: utzoo!attcan!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!POSTGRES.BERKELEY.EDU!dillon
From: dillon@POSTGRES.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga.tech
Subject: Exec's use of the user stack for a task
Message-ID: <8812180904.AA24272@postgres.Berkeley.EDU>
Date: 18 Dec 88 09:04:19 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Lines: 22


	This has come out of my recent experimentation with light weight
processes.  The stack pointer, A7, must at all times be pointing to at 
least (around) 96 bytes of storage below it because EXEC does indeed push
all the registers, PC, and condition codes onto it when switching between
tasks.

	This is unfortunate, because it forces me to allocate 96+N bytes of
stack for each LWP.  Ahh well, not terrible as two dozen LWPs only take
around 4K, but if EXEC had stored those registers in the Task structure
instead, it would have reduced the amount of memory needed by each LWP by
75% (70 bytes instead of 200) for small LWPs.  But, Alas, there is no way
to fix the problem without asking for major trouble.  So much for running
large cell-arrays under pseudo multitasking!

	Not to begrudge EXEC.  All in all EXEC has only 4 or 5 incorrectly
implemented items (use of the user stack, exceptions, lack of dynamic
priorities, the hardware screwup that placed the interrupt vectors, and
EXEC library base in chip memory).  In case nobody's figured it out, that's 
a pretty good record for the core of an operating system.

					-Matt