A/UX window systems, Mac toolbox, etc
Mike (My watch has windows) Meyer
In article <76...@apple.Apple.Com> gol...@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, m...@berkeley.edu
Enmimes sont les gougebosqueux, ucbvax!mwm
Et le momerade horsgrave. m...@ucbjade.BITNET
Karl Swartz
>[Followups have been pointed to comp.sys.68k.]
>
>In article <76...@apple.Apple.Com> gol...@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)
William C. Anderson
> 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 - w...@emx.utexas.edu
d...@datacube.uucp
I remember a rumor years back: When only the 68000 was available,
Apollo used two 68000 chips to implement Virtual Memory. One
executed instructions immediately following the other. When the
first one ran out of memory, the second would stop and do the context
switching needed for virtual memory.
Dave Erickson
----------------------------------------------
------ Datacube Inc.
/ /| 4 Dearborn Rd.
------ | Peabody, Ma 01960
|| \| | ihnp4!datacube!dje
|| /|/ Human:(617)535-6644
------ Fax: (617)535-5643
Carl Heinzl
>><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!"
) `|=(-
\------------'
Kim Kempf
>>In article <76...@apple.Apple.Com> gol...@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.
Brad Parker
> 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..."
br...@Cayman.com - from a (yet another) Smith's tune
J. Collier
Followup-To:
Mike (My watch has windows) Meyer (m...@eris.UUCP) writes:
>In article <76...@apple.Apple.Com> gol...@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 m...@berkeley.edu ucbvax!mwm m...@ucbjade.BITNET
-------------------------
James Collier Internet(ish): ja...@cantuar.uucp
Computer Science Dept., UUCP: {watmath,munnari,mcvax}!cantuar!james
University of Canterbury, Spearnet/Janet: j.co...@nz.ac.canty (unreliable)
Christchurch, New Zealand. Office: +64 3 482 009 x8356 Home: +64 3 554 025
Richard Kottke
>From article <3b219d...@apollo.uucp>, by hein...@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?
Daniel A. Glasser
>>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 d...@chinet.UUCP
One of those things that goes "BUMP!!! (ouch!)" in the night.
...!att-ih!chinet!dag | ...!ihnp4!mwc!dag | ...!ihnp4!mwc!gorgon!dag
Dave Haynie
> 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!"
Kurt Liebezeit
>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 da Silva
> 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*.
Nigel Horne
>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.
<n...@root.co.uk> G1ITH Fax: (01) 726 2750
Phone: +44 1 606 7799 Telex: 885995 UNISFT G BT Gold: CQQ173