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."