Path: utzoo!utgpu!water!watmath!clyde!ima!cfisun!palladium!nw
From: nw@palladium.UUCP (Neil W.)
Newsgroups: comp.sys.amiga
Subject: Re: Another 68020 difference
Summary: BSET *is* single-processor atomic, in absence of MMU
Message-ID: <531@palladium.UUCP>
Date: 25 Jun 88 14:50:03 GMT
References: <8806240024.AA11802@cory.Berkeley.EDU>
Reply-To: nw@palladium.UUCP (Neil W.)
Organization: Epoch Systems, Marlborough, MA
Lines: 63

In article <8806240024.AA11802@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
>
>	A friend of mine got caught by this one:
>
>	BSET is atomic, right?  OR.w #1,memory?
>
>	wrong
>
>	Guess what?  The 68020 has no compunction for interrupting an
>	instruction in the middle of its execution.
>
This isn't correct, unless I misunderstand what you are saying.

The 68020 samples interrupts generated by external devices *only*
on instruction boundaries; you will never see an interrupt handler
invoked in the middle of read and write cycles of any instruction.
On the Amiga, you will *never* see a process switch occur in the
middle of such an instruction.

One exception :-) to this rule is the Bus Error exception, aka "page
fault" on systems with an MMU.  The Bus Error exception can in
fact occur on *any* bus cycle.  Thus, this sequence of operations
is possible:

	- BSET reads memory
	- BSET modifies bit internally
	- BSET writes memory -- but wait! the write fails due to bus
	  error, because the page has been marked read-only and this
	  is a UNIX box with copy-on-write fork :-)
	- UNIX kernel copies the page, marks it writable, and is
	  preparing to return to your process.

At this point, if an external interrupt occurs, the interrupt handler
would in fact be able to modify the very same location that the
BSET instruction was trying to modify.

If this were to happen, then when the kernel returns from the bus
error exception, the write cycle of the BSET instruction will pick
up where it left off -- any modifications to the location made by the 
interrupt handler may in fact get trashed.  This happens because
the bus error exception works on a cycle-by-cycle basis, not on
an instruction-by-instruction basis.

A similar thing can happen with signal handlers on UNIX boxes.
Signal handlers get invoked by Berkeley-derived UNIX in the tail
end of the processor exception code.  Thus, it is possible that
a naive port of the vax "trap.c" code to a 680x0 box might make
it possible for a user signal handler to be invoked "in the middle"
of an instruction.  I consider this to be a bug in the kernel,
because it exposes a macro-inconsistent state of the machine to the
user process signal handler.  Things get especially strange if
the faulted instruction was a JSR that has to grow the stack.

>	So all those supposedly atomic single-instruction operations people
>have probably been doing, and not surrounding them with Forbid()/Permit(),
>create windows of vulnerability if you've got a 68020.

I don't think so, unless someone has ported a buggy UNIX implementation
to their Amigas :-)

-- 
Neil Webber / Epoch Systems, Marlboro MA / (617) 481-3717
        {harvard!cfisun, linus!alliant}!palladium!nw