Path: utzoo!attcan!uunet!mcvax!ukc!mupsy!mucs!rmd
From: rmd@r3.cs.man.ac.uk
Newsgroups: comp.arch
Subject: Synchronisation (was re: MIPS Architecture Question)
Keywords: synchronisation, read-modify-write
Message-ID: <5434@ux.cs.man.ac.uk>
Date: 16 Jan 89 13:31:41 GMT
Sender: news@ux.cs.man.ac.uk
Organization: University of Manchester, UK
Lines: 61

I don't know how MIPS ensure synchronisation, but it is possible to
implement a TAS instruction with a sequence of simpler instructions!

  As part of the MUSHROOM project we are designing a RISC style CPU
with support for multi-processing.  MUSHROOM does not have a
synchronistation instruction, but synchronistation is maintained by
clever use of the way the pipeline is resarted and a little
co-operation form the interrupt handlers.

  When an instruction is interrupted the pipeline is normally
re-started from that instruction, but in the case of the instruction
in the single delay slot following a branch instruction, the pipeline
is re-started at the branch instruction. This means that if the branch
and its delay slot instruction are both executed they *MUST* have been
executed indivisibly. This can be used to produce an indivisible
test-and-store operation.

  What we need to do now is to ensure that no interrupts have occurred
between the time the value was loaded and this test-and-store. This
works something along the lines of :

   start:	clear flag
	   	load value
	   	if flag set goto: start
	   	store new 
  The `flag' is kept permamently in a global register.  Any
interrupt routines which could trample over this code must set the
flag. Thus, if this sequence of instructions completes, the load and
store have been carried out indivisibly.

  Result: one TAS operation at the cost of one cycle added to some
interrupt routines, a global register and this extra bit of code
instead of a single, multi-cycle, hardware TAS instruction. For the
class of problems for which this processor is intended
(object-oriented / symbolic processing) our figures suggest that this
software solution will be more cost-effective than adding the
complexity of the synchronisation mechanisms to the hardware.

  This scheme could suffer complications with operations such as DMA,
but since in the MUSHROOM processor everything is done using
interrupts we do not suffer that problem.

So long and thanks for all the fish :
					Rhod

------------------------------------------------------------------
Rhodri M. Davies,    Room 2.90,    Department of Computer Science,
University of Manchester,  Oxford Road,  Manchester, M13 9PL, U.K.
Tel: +44-61-275 2000 ext 6149		    Internal: (Owens) 6149
JANET: rmd@uk.ac.man.cs.r5           UUCP: mcvax!ukc!man.cs.r5!rmd
------------------------------------------------------------------

So long and thanks for all the fish :
					Rhod

------------------------------------------------------------------
Rhodri M. Davies,    Room 2.90,    Department of Computer Science,
University of Manchester,  Oxford Road,  Manchester, M13 9PL, U.K.
Tel: +44-61-275 2000 ext 6149		    Internal: (Owens) 6149
JANET: rmd@uk.ac.man.cs.r5           UUCP: mcvax!ukc!man.cs.r5!rmd
------------------------------------------------------------------