🚀 go-pugleaf

In article <2581@intelca.UUCP> clif@intelca.UUCP (Clif Purkiser) writes:
>... I believe a very important
>consideration is that an on-chip MMU allows binary compatibility 
>between machines.  For instance on the Unix System for the 80386,

	blah, blah, blah...

>Contrast this with Unix systems that use processors with off-chip MMUs.
>If I want to buy an application for a 68020 machine I have to specify which 
>machine I am using Apollo, Masscomp etc. Eventhough all of the machines are 
>running Unix-like OS  and use the 68020...
>
>Clif Purkiser, Intel, Santa Clara, Ca.

Whoa there Clif! Turn off the flames.

Since when does the on-chip MMU or lack thereof matter to Unix
ISVs (read that Unix application vendors)?? The reason we have vendor-specific
code is primarily because Apollo, Masscomp etc. have different software
environments (Aegis vs RTU). The fact that their MMUs are different affects
only the hardware vendors themselves and then only their folks who develop and
maintain the operating systems. The people I work with don't care if the MMU
is on the chip or not, only whether one system out-performs another and
whether or not the ugliness of the architecture gets in our way. :-)

Granted, it was nice to see our application running on an early pre-announced
Compaq 386 -- the same binary that ran on an IBM PC/AT -- but why is that
any more remarkable than seeing our application running on both a Sun 2
(68010) and a Sun 3 (68020) without being recompiled or relinked?

The reason for the compatibility between the 386 and 286 is that the operating
system (ie software environment) was identical, not because the MMU was on-chip.
When we port to a real System V for the 386, all bets are off regarding binary
portability between that and Xenix!
-- 
                                    Mark Fox
       Applix Inc., 112 Turnpike Road, Westboro, MA 01581, (617) 870-0300
                    uucp:  seismo!harvard!halleys!applix!mark