mo@lbl-csam.ARPA (04/25/84)
From: (Mike O'Dell[x-csam])mo@lbl-csam.ARPA I suspect the Motorola port supports only the Motorola MMU which is, shall we be charitable, not the most inspired MMU design available. While Unisoft does indeed support the Motorola MMU chip, most of the more sucessful Uniboxes(TM) on the market have more powerful MMU's which are much more directly suited to the demands of modern systems. Does anyone know for sure whether the Motorola port supports alternate memory managers? -Mike O'Dell
hardy@sdccsu3.UUCP (05/09/84)
The Motorola port of Unix System V as currently shipped by Motorola only supports the EXORMACS MMU, which is a base and bounds design, and does not map in system state. Because of the way Motorola did the MMU code, it takes well over four milliseconds to effect a task switch, of which two milliseconds is at spl7. If you are planning on accepting input on a serial line at 9600 baud, prepare to drop characters. Also, Motorola has yet to release the source for the C Compiler becuase AT&T is trying to get more money from Motorola and Motorola's Customers. Supposedly, Motorola has the MC68451 Code working, but from the embryonic code embedded in the released System V sources, it will only work with the MC68010, and not the MC68000. This is because they disable all the segmentation registers at task start up and only load registers when they get a bus error. I suspect that this does not make AT&T totally unhappy, since many 68000 machines directly compete with their 3B series. Michael Christensen Unix System V Project Manager Alcyon Corporation
mjl@ritcv.UUCP (Mike Lutz) (05/20/84)
Just for the record, the Tropel Division of GCA has UNIX(*) running on
the same EXORMACS based system as the Motorola port. The difference is
that they started from V7 (well before System V was announced), but
have added lots of goodies from System III/V and the Berkeley
distributions since then. Also, they are not plagued with performance
spikes at each process switch.
Yes, the EXORMACS MMU is a bash & bound unit with translation disabled
in supervisor mode. This is a real loss for UNIX, as the kernel
implicitly assumes that the current process context is mapped onto
fixed kernal space addresses. From what I've been able to gather,
Motorola *simulates* mapping by constantly copying context information
into and out of a fixed buffer area -- obviously an expensive
operation.
The "tropix" design does *not* involve the huge 4 millisecond process
switch overhead nor 2 milliseconds at spl7 because most of the kernel
runs in *user* mode, so mapping is available. Reference the paper by
Mike Shon & me in the July 1983 USENIX Proceedings.
Mike Lutz
(*) UNIX is a Trademark of Bell Labs
--
Mike Lutz Rochester Institute of Technology, Rochester NY
UUCP: {allegra,seismo}!rochester!ritcv!mjl
ARPA: ritcv!mjl@Rochester.ARPA