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]