Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site oakhill.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!qantel!dual!lll-crg!mordor!ut-sally!oakhill!davet
From: davet@oakhill.UUCP (Dave Trissel)
Newsgroups: net.micro.68k
Subject: Re: Re**n: Bus Error Effluvia
Message-ID: <546@oakhill.UUCP>
Date: Thu, 3-Oct-85 02:04:21 EDT
Article-I.D.: oakhill.546
Posted: Thu Oct  3 02:04:21 1985
Date-Received: Sun, 6-Oct-85 05:01:45 EDT
References: <532@oakhill.UUCP> <2393@ut-ngp.UTEXAS> <536@oakhill.UUCP> <2442@ut-ngp.UTEXAS>
Reply-To: davet@oakhill.UUCP (Dave Trissel)
Distribution: net
Organization: Motorola Inc. Austin, Tx
Lines: 58

In article <2442@ut-ngp.UTEXAS> kjm@ut-ngp.UTEXAS (Ken Montgomery) 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
>>>
>>>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
>>
>>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.

The HLL would have a construct to do it.  Like the PL/I REORDER statement
prefix or special meaning to the PL/I null statement for 360/91.

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

For a given architecture one can think up something arbitrarily grody. For
example, how would a high-level language support the return of a 32-bit
value from an exception routine in a 16-bit architecture which only has 16 bit
registers and no 32-bit load instructions?  Would you classify all 16 bit
machines as therefor grody?

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

As I pointed out, the "problem" exists on every architecture and HLL
constructs can be made available to deal with such things.

>>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 question was originally what is a valid context when an exception (or
interrupt) occurs.  I merely pointed out that all architectures have these
anomalies when it comes to High Level Langauges. The '020 pipeline doesn't
really make matters any more difficult as long as the system programmer
fully understands the issues involved. No different than the programmer on a
16 bit machine understanding the issues involved there with 32-bit data.

  --  Dave Trissel   {seismo,ihnp4}!ut-sally!oakhill!davet
      Motorola Semiconductor Austin