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