dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (12/18/88)
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
mlelstv@faui44.informatik.uni-erlangen.de (Michael van Elst ) (12/20/88)
In article <8812180904.AA24272@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > > Not to begrudge EXEC. All in all EXEC has only 4 or 5 incorrectly >implemented items ... >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 Yes that is. BTW, EXEC Base is in C00000 memory if you have installed memory there. Any other memory is noticed after Exec is initialized, you would have to do a complete warm boot to use it. Michael van Elst E-mail: UUCP: ...uunet!unido!fauern!faui44!mlelstv
john13@garfield.MUN.EDU (John Russell) (12/20/88)
In article <8812180904.AA24272@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: >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). And C-A will be taking steps to rectify at least some of this in 1.4. The May/June '88 AmigaMail talks about how the exception base location may be changed on a 68010 or higher system and shows how to locate it. It mentions that serial I/O will be one of the prime beneficiaries... does anyone know what kind of speedup might be expected? Would this speedup be more noticeable at higher baud rates? (I may go 9600 baud in the new year.) Most developers may have remembered about the exception vectors, but a little reminder never hurts. John -- "Version 2.0 is advertised as supporting cursor keys." -- somewhat left-handed endorsement of a Mac word-processor :-)
dale@boing.UUCP (Dale Luck) (12/20/88)
In article <8812180904.AA24272@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: >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. You better give yourself a little extra if you ever use ieee libraries. The state of the 68881 requires atleast an extra 150 bytes. > > 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 You are right, addtask should allocate the stack space it needed to do a proper task swap. This way we could up if necessary. > > -Matt -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (12/21/88)
john13@garfield.MUN.EDU (John Russell) Writes:
:be changed on a 68010 or higher system and shows how to locate it.
:
:It mentions that serial I/O will be one of the prime beneficiaries... does
:anyone know what kind of speedup might be expected? Would this speedup be
:more noticeable at higher baud rates? (I may go 9600 baud in the new year.)
:
:Most developers may have remembered about the exception vectors, but a little
:reminder never hurts.
What it will hopefully do, coupled with fixing the keyboard.device's
long disabled sections that Bryce found, is remove all the overrun errors
we get at higher baud rates (19.2KB+), and with a 68010+ remove the problem
of the video mode causing overruns at high baud rates due to the CPU not
being able to process the interrupt fast enough.
-Matt