Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!db.toronto.edu!jonah
From: jonah@db.toronto.edu (Jeffrey Lee)
Newsgroups: comp.arch
Subject: Re: Instruction (dis)continuation
Message-ID: <1989Sep11.171747.16410@jarvis.csri.toronto.edu>
Date: 11 Sep 89 21:17:48 GMT
References: <1790@cs-spool.calgary.UUCP> <255@ssp1.idca.tds.philips.nl>
Lines: 44

roelof@idca.tds.PHILIPS.nl (R. Vuurboom) writes:
>In article <1790@cs-spool.calgary.UUCP> deraadt@enme3.UUCP (Theo Deraadt) writes:
>|In article <3267@scolex.sco.COM> seanf@sco.COM (Sean Fagan) writes:
>|Gad. How about a hardware FIFO? How about a serial receive buffer on
>|your generic serial chip? I really doubt this rumour, unless some special
>       What the solution is for your hardware fifo is something I'm
>still trying to figure out :-)

Most of the problems arise from the use of memory-memory instructions.
You SHOULD be OK if you write code that accesses ``critical'' locations
using only a RISC sub-set of the CISC instruction set.  That is if you
use register-register operations and single memory address move
instructions.  That is, convert:

	move fifo,addr1
	add  fifo,addr2

into:

	move fifo,reg
	move reg,addr1
	move fifo,reg1
	move addr2,reg2
	add  reg1,reg2
	move reg2,addr2

You can get away with:

	move fifo,reg
	move reg,addr1
	move fifo,reg
	add  reg,addr2

if addr2 is not a critical variable or the add instruction uses
guaranteed atomic read-modify-write access.

A respectable processor should NOT restart a move instruction with just
one memory operand if the read/write has succeeded.  Therefore an an
exception should not be able to cause the processor to restart the
instruction and re-read the data.  [No bets if the processor has a deep
pipeline--try checking the hardware reference manuals or calling the
manufacturer.]

j.