Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!killer!tness7!tness1!sugar!peter
From: peter@sugar.UUCP (Peter da Silva)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Amiga UNIX
Message-ID: <2178@sugar.UUCP>
Date: 25 Jun 88 14:34:26 GMT
References: <23602@hi.unm.edu> <354@faui44.informatik.uni-erlangen.de> <257@jackson.UUCP>
Organization: Sugar Land UNIX - Houston, TX
Lines: 51

In article <257@jackson.UUCP>, egranthm@jackson.UUCP (Ewan Grantham) writes:
> I'm just curious after all this discussion of how Commodore IS planning to
> implement Unix on the A2500?

Easy. Stick a 68020 and an MMU in and throw AmigaDOS out. I'm trying to
come up with some ideas of how to stick a 68020 and MMU in and run UNIX
tasks under AmigaDOS. The trick (for those who got bored with the flames
started by my offhand comment about performance) is to think of the Amiga
Exec as the kernel.

In UNIX, when you perform a system call or get an interrupt the process you're
running switches into kernel mode. All the processing is done in the context
of the process running at the time (including device drivers, and so on).
Contrast this with AmigaDOS, where device drivers are just other tasks. Why
is it so?

It's because in UNIX switching context to another process is (by comparison
with the Amiga) expensive. In the Amiga you save and restore the registers
and a couple of pointers. Given that the Amiga supports the Motorola FPU, it
probably saves and restores *its* registers as well. In UNIX you also have to
save and restore the MMU state. This can be expensive. For example, the Sun
uses an MMU with 8 or 16 contexts in it, so for up to that many processes
context switch is fast. When you get more active processes you get a
perceptible loss in performance.

So the drivers don't get their own tasks. They run in the context of the
current process and avoid those extra context switches.

Let's get back to user and kernel mode. Swapping between user and kernel mode
is cheap... about as cheap as an Amiga context switch. That's because in
kernel mode the MMU is pretty much unused. The kernel is trusted not to
diddle with the wrong things (all this is one reason why UNIX kernel hackers
are in demand: it's a lot harder than writing a well-behaved program on the
Amiga).

My suggestion was along these lines: only use the MMU in the context of a UNIX
process. Turn it off when you get an interrupt (switch to kernel/amiga mode) or
make a system call (switch to kernel/amiga mode). Turn it on again when you
get back to the UNIX process. You will have to be careful what memory you
allocate to the UNIX process: don't want to fragment the MMU tables *too* much.

But look what you get: you get UNIX compatibility (care of unix.library and
the 68020 (or 68030!)), with a *fast* real-time kernel that's *easy* to work
in (compared to a real UNIX kernel). Move aside, Masscomp: Commodore's
coming!

Well, I can dream...
-- 
-- `-_-' Peter (have you hugged your wolf today?) da Silva.
--   U   Mail to ...!uunet!sugar!peter, flames to /dev/null.
-- "A foolish consistancy is the hobgoblin of little minds".