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!bonnie!akgua!whuxlm!harpo!decvax!genrad!mit-eddie!think!harvard!seismo!ut-sally!oakhill!davet
From: davet@oakhill.UUCP (Dave Trissel)
Newsgroups: net.micro.68k,net.micro.16k
Subject: Re: Re: Bus Error Effluvia
Message-ID: <526@oakhill.UUCP>
Date: Tue, 10-Sep-85 20:45:27 EDT
Article-I.D.: oakhill.526
Posted: Tue Sep 10 20:45:27 1985
Date-Received: Fri, 13-Sep-85 04:12:41 EDT
References: <124@desint.UUCP> <5913@utzoo.UUCP> <44@l5.uucp> <1614@druil.UUCP> <57@intelca.UUCP>
Reply-To: davet@oakhill.UUCP (Dave Trissel)
Organization: Motorola Inc. Austin, Tx
Lines: 67
Xref: watmath net.micro.68k:1113 net.micro.16k:385

In article <57@intelca.UUCP> kds@intelca.UUCP (Ken Shoemaker) writes:

>thinking about it for a little while, I can think of at least two problems
>that this might cause.
>
>1) Since the processor can't get out onto the bus if it is busy either waiting
>	for ready or a bus error, one wouldn't think that it could corrupt
>	anything that is not recoverable.  However, it can fiddle around
>	with its internal state all it wants to.  Now, if one of the things
>	that it does internally is muck with some registers (a completely
>	valid thing to do) that would get changed as a result of the trap
>       handler, we have a problem, I would think.  This seems real special
>	case, though I do remember that at least some early versions of
>	4BSD paid attention to how register variables were allocated by the
>	c compiler, and used this information when mixing assembly with
>	c code...

This problem occurs for any architecture that does not do all operations
memory-to-memory.  [Is this a plug for the TMS1600? :-)]  Consider a person
forcing a breakpoint while debugging a program.  If the debugger gains
control anywhere during an instruction sequence which uses data registers
to compute a value destined for a memory location then there's problems.

  Example: The HLL statement is I = J + K.   The psudeo assembler code is

		 LOAD  J to Reg
		 ADD   K to Reg
		 STORE Reg to I

If the hardware breakpoint occurs after the LOAD than any debugger displays
or changes to I, J or K will not give the expected result.  This relates
specifically to the case you are getting at of values being held in registers
during an interrupt.

Of course, the same would be true if instead of a breakpoint switch being
pressed the task context was stored due to a task timeout.  The problem
of valid variable access is still the same.

Any software which has to deal with multi-tasking variables on any machine
will have to take great care in handling them because of this and other
problems.  The long stack store for bus-errors on the MC68020 is just a
variation of the same theme.   That was a primary reason for the addition of
the '020 CAS (Compare and Swap) and CAS2 instructions on the '020. These
use locked bus cycles which allow changing of values without contamination
by interrupt routines.

>2) In the same tack, I think that if Mot ever includes a data cache on their
>	chip, they will have to pay special attention to the amount of
>	concurrency they allow for data accesses on both the external bus
>	and the internal cache bus.

The problems have nothing to do with caches but with deeply layered pipe
design.  And they are essentially no different for the M68000 architecture
and any other.

>So what do y'all think?  Does anyone know exactly what the thing tosses on the
>bus, and whether it is possible for the trap handler to modify the return
>state such as to change the results of half-executed instructions
>(or whole executed instructions after the bus-error write)?

Again, what's the difference between half-executed instructions and half-
executed assignment statements.  In either case the variable is untouchable.
In any case, there is a simple technique for completing the instruction
out of the bus error handler - just set the trace bit on in the Status Reg.

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