mwm@eris (Mike (My watch has windows) Meyer) (03/15/88)
[Followups have been pointed to comp.sys.68k.]
In article <7670@apple.Apple.Com> goldman@apple.UUCP (Phil Goldman) writes:
<I think one point you are both missing out on is that preemptive multitasking
<requires hardware support not available on a 68000.
Right. So how did Sun, Apollo, Amiga, Sage, Stride and a multitude of
others manage to market 68000 systems that did preemptive
multitasking?
All you need to manage preemptive multitasking is a way to take
interrupts that allows you to save the old context, and the mechanisms
needed for a non-preemptive scheduler.
Being able to save the old context can be a bear - you have to either
not interrupt instructions, or be able to rewind/restart an
instruction. On the 68K, about the only thing that causes serious
problems is bus & address errors. Address errors are sufficient to
abort the processes causing it (or panic the OS). Bus errors do the
same in non-VM systems. In vm systems, they could indicate a page
fault, which has to be dealt with.
Here is where the 68000 has problems: there's not enough information
around to restart a process that page faults in the middle of some
instructions. The 68010 & later processors fixed this. But people
found ways around that problem with thoe 68000.
<-Phil Goldman
<Apple Computer
<mike
--
Il brilgue: les toves lubricilleux Mike Meyer
Se gyrent en vrillant dans le guave, mwm@berkeley.edu
Enmimes sont les gougebosqueux, ucbvax!mwm
Et le momerade horsgrave. mwm@ucbjade.BITNETkls@ditka.UUCP (Karl Swartz) (03/23/88)
In article <7681@agate.BERKELEY.EDU> mwm@eris.UUCP (Mike (My watch has windows) Meyer) writes: >[Followups have been pointed to comp.sys.68k.] > >In article <7670@apple.Apple.Com> goldman@apple.UUCP (Phil Goldman) writes: ><I think one point you are both missing out on is that preemptive multitasking ><requires hardware support not available on a 68000. > >Right. So how did Sun, Apollo, Amiga, Sage, Stride and a multitude of >others manage to market 68000 systems that did preemptive >multitasking? Neither Sun nor Apollo ever marketed systems based on the 68000, to the best of my knowledge. The Sun-2 uses a 68010, while the Sun-3 family uses a 68020. Likewise, I believe Apollo's are based on these processors (larger models now use some custom stuff) and not the vanilla 68000. Not that this implies that multi-tasking is impossible on the 68000. The Amiga is a prime counter example. -- Karl Swartz |UUCP decvax!formtek!ditka!kls 1-412/937-4930 office | {floyd,pitt,psuvax1}!idis!formtek!ditka!kls |BIX kswartz "I never let my schooling get in the way of my education." (Twain)
wca@ut-emx.UUCP (William C. Anderson) (03/27/88)
In article <215@ditka.UUCP>, kls@ditka.UUCP (Karl Swartz) writes: > Neither Sun nor Apollo ever marketed systems based on the 68000, > to the best of my knowledge. Sorry Karl, the original Sun-1 used a MC68000, ran Unisoft V7 and had no demand-paged virtual memory; it merely swapped jobs, and did a pretty poor job of that. I worked on one of these beasts. Only the Sun-1U (upgrade) could actually run 4.2BSD (before they started to call it SunOS). Don't know about Apollo; for a long time they were based on a proprietary (or maybe AMD, who knows?) bit-sliced processor. William Anderson - University of Texas CompCenter - wca@emx.utexas.edu
kim@mcrware.UUCP (Kim Kempf) (03/30/88)
>In article <7681@agate.BERKELEY.EDU> mwm@eris.UUCP (Mike (My watch has windows) Meyer) writes: >>In article <7670@apple.Apple.Com> goldman@apple.UUCP (Phil Goldman) writes: >><I think one point you are both missing out on is that preemptive multitasking >><requires hardware support not available on a 68000. >> >>Right. So how did Sun, Apollo, Amiga, Sage, Stride and a multitude of >>others manage to market 68000 systems that did preemptive >>multitasking? OS-9 is pre-emptive multitasking and runs on the 68000. For that matter, OS-9 did it on the 6809 (e.g. Tandy Color Computer). Such facilities are not necessarily provided by the hardware but by the skill and ingenuity of the programmer... Kim Kempf Microware Systems Corporation.
james@cantuar.UUCP (J. Collier) (03/31/88)
Sender: Followup-To: Mike (My watch has windows) Meyer (mwm@eris.UUCP) writes: >In article <7670@apple.Apple.Com> goldman@apple.UUCP (Phil Goldman) writes: ><I think one point you are both missing out on is that preemptive multitasking ><requires hardware support not available on a 68000. > >Right. So how did Sun, Apollo, Amiga, Sage, Stride and a multitude of >others manage to market 68000 systems that did preemptive >multitasking? [Mike goes on to explain that 68000 instructions can be restarted after most exceptions other than bus & address errors. This hampers the use of paged virtual memory, but *not* pre-emptive multitasking] As Mike says, the problems with pre-emptive multitasking on the Mac can't be blamed on the 68000 architecture. The difficulty is in determining whether process exchange would leave shared OS and Toolbox structures in an inconsistent state. Normally [slightly bold] this is done by ensuring that such inconsistencies can arise only during the execution of a single system call, and by switching the processor from user (unprivileged) to supervisor mode during system calls. The process dispatcher is inhibited when the S-bit is set. Memory protection usually plays a part in this as well, but that's another story. Unfortunately, the Mac Toolbox/OS falls down twice: 1) the processor is *always* in supervisor mode 2) A certain amount of state information which would apply only to particular process is stored globally within the system during the execution of user code. For all this, pre-emptive multitasking on the Mac can be [and has been] done. Part of my MSc thesis involved the implementation of a multi-threaded window server on the Mac, and for reasons of stubbornness I persevered with pre-emptive multitasking. To get around (1), you have to simulate the S-bit in software. You replace the trap dispatcher (very, very carefully) with one which records whether the system is executing in the context of a trap. The standard trap dispatcher jumps directly to the required routine; this version must fiddle the exception address so that the simulated S-bit is cleared before the return to user code. Various tricks are required to ensure that this process is invisible to certain hideous ROM patches which look down the stack to see where they were called from. (Thanks to Scott Knaster for pointing this out). (2) is trickier. The process dispatcher has to test for the appropriate conditions before proceeding, and/or save and restore the various pieces of state information with each context switch. To some extent this is also necessary with non-preemptive multitasking (Multifinder, Switcher), so the solutions are not new. Another difficulty comes from running the process dispatcher off the 60Hz VIA interrupt. The scheduler can be installed as a VBLtask, but in order to protect against possible unbounded stack growth it is necessary to install the dispatcher as the last interrupt task so that it can RTE directly into the new context. Again, this involves replacing the interrupt handler. Admittedly this system was designed to run code files which were linked specifically for the window server, rather than full-blown applications. The server looks after DA support, window management, event preprocessing etc., so its 'sub-applications' don't have so many conflicting requirements. I couldn't believe the reports on Multifinder until I saw it in action; all praise to those responsible. But given that applications can be integrated in this way, I can't see why pre-emptive application multitasking should be considered impossible. Unless Multifinder relies on the application's not calling GetNextEvent() at inopportune moments... Is there something I have missed? Is interactive performance the issue? Or is it just not worth the effort? ><-Phil Goldman ><Apple Computer > > Mike Meyer mwm@berkeley.edu ucbvax!mwm mwm@ucbjade.BITNET ------------------------- James Collier Internet(ish): james@cantuar.uucp Computer Science Dept., UUCP: {watmath,munnari,mcvax}!cantuar!james University of Canterbury, Spearnet/Janet: j.collier@nz.ac.canty (unreliable) Christchurch, New Zealand. Office: +64 3 482 009 x8356 Home: +64 3 554 025