Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!apple!oliveb!amiga!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga
Subject: Re: 68040 vs 80246 (Was Re: Xerox sues Apple!!!)
Message-ID: <9125@cbmvax.commodore.com>
Date: 22 Dec 89 02:52:14 GMT
References: <1617@bnr-rsc.UUCP>
Organization: Commodore, West Chester, PA
Lines: 47

in article <1617@bnr-rsc.UUCP>, schow@bcarh185.bnr.ca (Stanley T.H. Chow) says:
> Summary:
> Followup-To:
> Keywords:

> How about the inconsistancy between 68000 & 68010? (Specifically the MOVESR
> problem).

Easily enough handled by the OS; in the Amiga OS, you say GetCC() and it works
on any system.  Like I mentioned in a previous article, the 68000 was never
designed to handle virtual memory or act as a virtual machine, and it shows.
But it's no big deal.  The other thing is that the only problem executing 
MOVE SR on a non-68000 causes in user mode is an exception that's trivial
to fix with a simple trap handler.  There are about 3 or more of these trap
handlers around for the Amiga OS; I use one called DeciGel, it works great
on those 1 or 2 programs that didn't use GetCC().

> For myself, I prefer the Intel approach - that is, make the successors
> have exactly the same bugs as well. That way, a pin-compatible '010 will
> really be pin-compatible.

When each chip needs to have a brand new mode, plus emulations of all the
prior modes, you might as well throw the bugs in.  The 680x0 chips are
still all user-mode compatible, so there's no emulation and no reason to
propagate any bug than can be easily fixed with a trap or something (in
that the MOVE SR problem is the only real incompatibility I've run into
across the family).

> How about the '020 MMU being a subset of the '851 MMU? Not a bug, but
> certainly an extremely undesirable feature for a later member of any
> architecture family.

That's the '030 MMU, and while it's a subset, it's a pretty substantial
subset.  Mostly they cut out a couple of addressing modes here and there,
most of the instructions, the way the MMU works, etc. is the same.  But
who cares, that's a supervisor mode change.  Motorola makes them when 
they make good architectural sense.  No big deal, you fix the kernel.
It's never been a big deal; in fact, for AMIX they just use the common
set of MMU instructions, far as I know.  Sun had to modify their kernel,
but they were using a hand-rolled MMU in their '020 machines anyway.
All the programs still work because user mode stuff doesn't change.

> Stanley Chow        BitNet:  schow@BNR.CA
-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
                    Too much of everything is just enough