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]