Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site mtxinu.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!qantel!dual!unisoft!mtxinu!ed From: ed@mtxinu.UUCP (Ed Gould) Newsgroups: net.micro.68k Subject: Re: Re**n: Bus Error Effluvia Message-ID: <467@mtxinu.UUCP> Date: Wed, 18-Sep-85 20:41:06 EDT Article-I.D.: mtxinu.467 Posted: Wed Sep 18 20:41:06 1985 Date-Received: Sun, 22-Sep-85 05:37:15 EDT References: <69@intelca.UUCP> <532@oakhill.UUCP> <2393@ut-ngp.UTEXAS> Reply-To: ed@mtxinu.UUCP (Ed Gould) Distribution: net Organization: mt Xinu, Berkeley, CA Lines: 24 Summary: >In article <532@oakhill.UUCP> oakhill!davet (Dave Trissel) writes: >>This is very easy for the '020 programmer to solve. The MC68020 NOP >>instruction serializes the machine (e.g. guarantees all updates for previous >>instructions have been done.) Therefore, by thowing in a NOP after the >>instruction which does the write such a loop on the '020 will always >>properly execute. In article <2393@ut-ngp.UTEXAS> kjm@ut-ngp.UTEXAS (Ken Montgomery) writes: >How does one get this NOP generated in the correct places for compiled code >that has to be portable? The synchronizing effect is not useful unless one >can manage to invoke it. Even if one solves this problem, the problem of >detecting all of the places where it is needed remains. 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 mt Xinu, 2910 Seventh St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."