heinzl_c@apollo.uucp (Carl Heinzl) (03/29/88)
>><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. This is incorrect. Apollo DN600 (do not confuse with DN660), 400 and 420 are all 68000 based machines. They use an arrangement of Dual 68000 cpus to allow preemptive multitasking. Basically, one of the processors does the error handling when a page fault is taken while the other preserve machine state (making it restartable). I also believe that the SUN model 1 series use dual 68000 cpus. The model 2 series was 68010 based and now their model 3's are 68020. > >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) > Carl G. Heinzl apollo.UUCP (617) 256-6600 x 7153 ____________ ____/--\____ \______ ___) ( _ ____) "Damn it Jim!, __| |____/ / `--' I'm a programmer not a Doctor!" ) `|=(- \------------'
brad@cayman.COM (Brad Parker) (03/30/88)
From article <3b219db7.d858@apollo.uucp>, by heinzl_c@apollo.uucp (Carl Heinzl): > This is incorrect. Apollo DN600 (do not confuse with DN660), 400 and 420 > are all 68000 based machines. They use an arrangement of Dual 68000 > cpus to allow preemptive multitasking. Basically, one of the processors No doubt 600 others will also respond to this. The issue here is not preemptive multitasking ("What bubba meant to say was...") The issue here is recovering from a bus error. The demand paging support (read hardware) generates a bus error when a logical page is not mapped to a physical page. The 68000 can not cleanly restart an instruction stream after a bus error (not all of the processor state is stacked) Film at 11. ;-) -brad -- Brad Parker Cayman Systems "You are sleeping; you don't want to believe..." brad@Cayman.com - from a (yet another) Smith's tune
richardk@puff.cs.wisc.edu (Richard Kottke) (03/31/88)
In article <903@cayman.COM> brad@cayman.COM (Brad Parker) writes: >From article <3b219db7.d858@apollo.uucp>, by heinzl_c@apollo.uucp (Carl Heinzl): >> This is incorrect. Apollo DN600 (do not confuse with DN660), 400 and 420 >> are all 68000 based machines. They use an arrangement of Dual 68000 >> cpus to allow preemptive multitasking. Basically, one of the processors > >No doubt 600 others will also respond to this. The issue here is not >preemptive multitasking ("What bubba meant to say was...") The issue >here is recovering from a bus error. The demand paging support (read Recovering from a bus error is a problem only if the system uses a virtual memory scheme (which it would if it was running UN*X.) If the system was running, say, OS-9/68k, then virtual memory is not required and the bus error is a real bus error, not a flag indicating that a new page needs to be brought in. Since it is not hard to port a UN*X application to OS-9 (especially if its in C), OS-9/68k was an obvious choice when only the 68000 was available. So why didn't anyone base a machine on it? I dunno. It seems like the history of computers shows the hardware designer making faster machines with bigger memory, and the computer scientist making compilers and operating systems to bring the speed back down to a PDP-8. The only advantage is that it becomes easier and faster to code more complex programs. Will it ever end?
dag@chinet.UUCP (Daniel A. Glasser) (03/31/88)
In article <1525@puff.cs.wisc.edu> richardk@puff.WISC.EDU (Richard Kottke) writes: >>No doubt 600 others will also respond to this. The issue here is not >>preemptive multitasking ("What bubba meant to say was...") The issue >>here is recovering from a bus error. The demand paging support (read > > Recovering from a bus error is a problem only if the system uses a virtual >memory scheme (which it would if it was running UN*X.) If the system was >running, say, OS-9/68k, then virtual memory is not required and the bus error >is a real bus error, not a flag indicating that a new page needs to be brought >in. I believe that the dual-68000 machines did support virual memory... One 68k was a little ahead of the other, and when the first would have a buss error, the second would be stopped until the first had corrected the situation that caused the buss error. The second would then be interrupted and its state loaded into the first, and both would then continue as if nothing had happened. That was the point of the dual 68k's. Somehow I get the impression from reading the article to which this is a follow-up that people have forgotten that Unix runs on machines without virtual memory, and that Unix was originally designed for machines without virtual memory. It was not until a few years ago that Unix on a Vax actually supported demand paging for process growth and swapping. I run UNIX on a machine without paged memory. -- Daniel A. Glasser dag@chinet.UUCP One of those things that goes "BUMP!!! (ouch!)" in the night. ...!att-ih!chinet!dag | ...!ihnp4!mwc!dag | ...!ihnp4!mwc!gorgon!dag
daveh@cbmvax.UUCP (Dave Haynie) (04/01/88)
in article <3b219db7.d858@apollo.uucp>, heinzl_c@apollo.uucp (Carl Heinzl) says: > This is incorrect. Apollo DN600 (do not confuse with DN660), 400 and 420 > are all 68000 based machines. They use an arrangement of Dual 68000 > cpus to allow preemptive multitasking. It's not the preemptive multitasking that this is needed for... > Basically, one of the processors > does the error handling when a page fault is taken while the other > preserve machine state (making it restartable). yes, we have it here. Page Fault. As in, virtual memory. When the CPU tries to access memory that isn't in the system, it gets a page fault, that memory is brought in from mass storage, and then the instruction is either continued or restarted. The 68000 certainly doesn't allow either instruction continuation or restart, thus the two 68000 scheme. On the 68010, they added instruction continuation, so eveything's cool at that level on up. >>Not that this implies that multi-tasking is impossible on the >>68000. The Amiga is a prime counter example. The 68000 handles preemptive multi-tasking just fine. It would work just fine with an MMU, too. But it's not going to allow any virtual happenings without some serious black magic, like maybe a second 68000. Fortunately for anyone concerned these days, 68010s are available and pin compatible. > Carl G. Heinzl apollo.UUCP > (617) 256-6600 x 7153 -- Dave Haynie "The B2000 Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
klieb@tekigm2.TEK.COM (Kurt Liebezeit) (04/04/88)
In article <1525@puff.cs.wisc.edu> richardk@puff.WISC.EDU (Richard Kottke) writes: > Since it is not hard to port a UN*X application to OS-9 (especially if its >in C), OS-9/68k was an obvious choice when only the 68000 was available. So >why didn't anyone base a machine on it? I dunno. The reason why is that OS-9/68k came out several years after the 68000 was introduced. The folks at Microware could probably pin it down exactly, but I think that OS-9/68k came out in early 1985. The 68010 was already available at that point. There are some nice machines out there that run OSK (as it is called informally), but they are not in the mainstream of consumer computing. Kurt Liebezeit
peter@sugar.UUCP (Peter da Silva) (04/04/88)
In article <1525@puff.cs.wisc.edu>, richardk@puff.cs.wisc.edu (Richard Kottke) writes: > Recovering from a bus error is a problem only if the system uses a virtual > memory scheme (which it would if it was running UN*X.) If the system was > running, say, OS-9/68k, then virtual memory is not required and the bus error > is a real bus error, not a flag indicating that a new page needs to be brought > in. Sorry, but UNIX does not imply demand paged virtual memory. We have a couple of 68000-based UNIX boxes not 4 feet away from me right now. I can't say why OS/9 hasn't caught on more than it has, but I suspect that Microware's licensing policies may have something to do with it, judging by what I have heard of them. OS/9 has some fundamental design differences from UNIX that do make it a pain to do the ports, also. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
njh@root.co.uk (Nigel Horne) (04/05/88)
>I think one point you are both missing out on is that preemptive multitasking >requires hardware support not available on a 68000. Wrong. Wrong. Wrong. The 68000 lacks the hardware to support a VM implementation of UN*X, specifically it doesn't write enough information on the stack during an interrupt to allow an instruction to be restarted - this was changed on the 68010. However non-VM implementations (remember those) can run on a 68000. Version 7 UN*X (UniPlus+ to be exact) was available before 68010s were. I have personally ported UNIX to several machines running with a 68000 CPU not with a 68010. -Nigel -- -- Nigel Horne, Director of Quality and Programmes, UniSoft Ltd. <njh@root.co.uk> G1ITH Fax: (01) 726 2750 Phone: +44 1 606 7799 Telex: 885995 UNISFT G BT Gold: CQQ173