Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/13/84; site intelca.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!qantel!hplabs!intelca!kds
From: kds@intelca.UUCP (Ken Shoemaker)
Newsgroups: net.micro.68k
Subject: Re: Re: Re**n: Bus Error Effluvia
Message-ID: <107@intelca.UUCP>
Date: Wed, 2-Oct-85 22:29:17 EDT
Article-I.D.: intelca.107
Posted: Wed Oct  2 22:29:17 1985
Date-Received: Sun, 6-Oct-85 06:44:30 EDT
References: <2393@ut-ngp.UTEXAS> <467@mtxinu.UUCP> <2439@ut-ngp.UTEXAS>
Distribution: net
Organization: Intel, Santa Clara, Ca.
Lines: 49

> >How does one write in a high-level language the idea that a store
> >might fault, that the fault is acceptable, and knowledge of the
> >fault status is in r0?  This sort of code *isn't* portable (which
> >may be an argument for not using it), and happens only in deliberate,
> >thereby known, places.  [Ed Gould]

certainly, this isn't portable among different architectures.  However,
the knowledge can be build as to register usage in a compiler (actually,
it must be).  I remember some of the early versions of Berkeley VAX unix
used the knowledge of the way register variables were allocated by the
c compiler in mixing assembly code with compiler code, so such a piece 
of code could be written that would mix low level interrupts (or bus
errors) with a high level language.  Also, for many systems, code must
be written to be non-portable, simply because the peripherals in the
processor subsystem (e.g., timers, etc.) are different.

If I were to write a piece of such code for a VAX780, I would expect it
to work the same on a VAX750.  Even such a kludgy piece of code as was written
in the original article probably would work.  Its a shame the same isn't
true between the 68010 and 68020, even if the external memory management
unit is the same.  Honestly, this is a minor thing.  My main point was
that moving from a 68* to a 68* may not be as simple as plugging in
a new component, even if everything else in the system is the same because
of changes other than architecture changes, but rather because of micro-
architecture changes.

Another assumption was made in the arguments about the 68020 bus effulvia,
in that it is assumed that it is required.  Certainly, this is true
with their current implementation, but if they had done an implementation
in a way that kept track of changes internally between bus requests and
bus acknowledges, they could set the processor to redo the instructions.
Performance in this case is a nit, since you are probably entering a very
slow operation anyway (e.g., paging), and besides, you probably would
take at least as long to dump all the crap on the external bus.  Whatever,
I have no idea whether such a scheme would even be implementable in
their transistor budget, but such a scheme would certanly be cleaner from
an external standpoint.  Note that for the most part, with this scheme
they could still pipeline out the wazoo if they so desired, so you still
get optimal performance for the normal case, i.e., no bus errors at all.
-- 
...and I'm sure it wouldn't interest anybody outside of a small circle
of friends...

Ken Shoemaker, Microprocessor Design for a large, Silicon Valley firm

{pur-ee,hplabs,amd,scgvaxd,dual,qantel}!intelca!kds
	
---the above views are personal.  They may not represent those of the
	employer of its submitter.