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.