Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ut-ngp.UTEXAS
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!ut-sally!ut-ngp!kjm
From: kjm@ut-ngp.UTEXAS (Ken Montgomery)
Newsgroups: net.micro.68k
Subject: Re**n: Bus Error Effluvia
Message-ID: <2393@ut-ngp.UTEXAS>
Date: Mon, 16-Sep-85 22:53:55 EDT
Article-I.D.: ut-ngp.2393
Posted: Mon Sep 16 22:53:55 1985
Date-Received: Wed, 18-Sep-85 03:58:20 EDT
References: <69@intelca.UUCP> <532@oakhill.UUCP>
Distribution: net
Organization: UTexas Computation Center, Austin, Texas
Lines: 33

[reposted since I don't think it got out the first time...]

In article <532@oakhill.UUCP> oakhill!davet (Dave Trissel) writes:

>In article <69@intelca.UUCP> kds@intelca.UUCP (Ken Shoemaker) writes:
>
>>bus fault handler, you have to be very careful, since (if r0 is used to
>>pass back values)
>>
>>loop:
>> mov     to-fault-location,blah
>> cmp     r0,1
>> jnz     loop
>>
>
>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.

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.

--
The above viewpoints are mine.  They are unrelated to
those of anyone else, including my cat and my employer.

Ken Montgomery  "Shredder-of-hapless-smurfs"
...!{ihnp4,allegra,seismo!ut-sally}!ut-ngp!kjm  [Usenet, when working]
kjm@ngp.UTEXAS.EDU  [Internet, if the nameservers are up]