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!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!ut-sally!oakhill!davet From: davet@oakhill.UUCP (Dave Trissel) Newsgroups: net.micro.68k Subject: Re: Re**n: Bus Error Effluvia Message-ID: <536@oakhill.UUCP> Date: Tue, 17-Sep-85 05:49:55 EDT Article-I.D.: oakhill.536 Posted: Tue Sep 17 05:49:55 1985 Date-Received: Thu, 19-Sep-85 04:31:50 EDT References: <69@intelca.UUCP> <532@oakhill.UUCP> <2393@ut-ngp.UTEXAS> Reply-To: davet@oakhill.UUCP (Dave Trissel) Distribution: net Organization: Motorola Inc. Austin, Tx Lines: 60 In article <2393@ut-ngp.UTEXAS> kjm@ut-ngp.UTEXAS (Ken Montgomery) 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. 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. 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. For example, what if another bit of code (in the same task or any other) happened to write to the same memory location? Would it find it's register clobbered? Would the exception handler bomb the machine because it only expected one special task to try the write? 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. 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. The IBM PL/I compilers, for example, would automatically produce a NOP for the highly pipelined 360 model 91 (I think it was) whenever a null statement (just a semicolon) was encountered in the program. That NOP did the similar function of serializing the pipe on that machine. Architectures also provide for locks and semaphores as proper means to access data shared by multiple tasks and/or processors. The Intel 808x has a LOCK prefix which can be used on most instructions. Motorola has TAS (Test and Set) and CAS (Compare and Swap). Usually computer system designers will add their own conventions such as special dual-ported memories or queueing circuits to be used in combination with, or enhance, methods provided by the microprocessor itself. -- Dave Trissel {ihnp4,seismo}!ut-sally!oakhill!davet