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".