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!hao!hplabs!intelca!amdcad!amd!vecpyr!lll-crg!mordor!ut-sally!ut-ngp!kjm
From: kjm@ut-ngp.UTEXAS (Ken Montgomery)
Newsgroups: net.micro.68k
Subject: Re: Re**n: Bus Error Effluvia
Message-ID: <2442@ut-ngp.UTEXAS>
Date: Mon, 30-Sep-85 18:46:44 EDT
Article-I.D.: ut-ngp.2442
Posted: Mon Sep 30 18:46:44 1985
Date-Received: Thu, 3-Oct-85 06:36:22 EDT
References: <532@oakhill.UUCP> <2393@ut-ngp.UTEXAS> <536@oakhill.UUCP>
Distribution: net
Organization: UTexas Computation Center, Austin, Texas
Lines: 58

[]
>>>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.  [Dave Trissel]
>>
>>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.  [Ken Montgomery]
>
>First of all, Ken's code above is not portable, and is not meant to be so.
>It will only work in a system were you are the software/hardware designer and
>have complete control over interrupt handlers and the hardware memory map
>of the machine.  [Dave Trissel]

Touche, but one would, on occasion, like to be able to do this cleanly
in an HLL.  Having to generate NOPs in odd places is grody.

>Second of all, each architecture has specific methods which must be followed
>to guarantee proper communication between different tasks or between tasks
>and interrupt exception routines.  Although the above code is usefull for
>investigating pipeline subtleties it is not the proper way to communicate
>since it makes unwarrented assumptions about its environment. [...]
>[Dave Trissel]

This sounds like you're saying you have to make assumptions that you're
not allowed to make...

>In other words, there is an agreement here between the interrupt handler
>and this piece of code AND an underlying assumption about the MPU involved.
>Compiler's simply don't expect this kind of side-effect and therefore have no
>reason to prepare for it.  [Dave Trissel]

Which is precisely one reason why I object to this sort of architectural
grodiness.

>If you are using an intermediate language for systems program and do want to
>produce something that works then certainly the language itself would have
>the capability of recognizing when to use a  NOP (in the case of the '020)
>or allow you to insert an embedded assembly language statement for the same
>effect.  [...]  [Dave Trissel]

More of the same sort of grodiness.

>Architectures also provide for locks and semaphores as proper means to access
>data shared by multiple tasks and/or processors. [...]  [Dave Trissel]

What does this have to do with pipeline synchronization?

--
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]