Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc!uxc.cso.uiuc.edu!mcdurb!aglew
From: aglew@mcdurb.Urbana.Gould.COM
Newsgroups: comp.arch
Subject: Re: Complex Instructions
Message-ID: <28200302@mcdurb>
Date: 28 Apr 89 17:49:00 GMT
References: <38629@bbn.COM>
Lines: 27
Nf-ID: #R:bbn.COM:38629:mcdurb:28200302:000:1426
Nf-From: mcdurb.Urbana.Gould.COM!aglew    Apr 28 12:49:00 1989


>Once in a while, the atomic nature of a complex instruction can have
>real advantages over a sequence of fast single cycle instructions.
>Because the complex instruction cannot be interrupted in mid sequence,
>there is no need to modify processor priority. This can allow better
>manipulation of shared data items (linked lists, counters, etc.)
>especially by user level processes. Anybody got a good way for a user
>execute an un-interupted sequence of a dozen RISC instructions ?

Don't rely on "the atomic nature of a complex instruction".

1) they may be restartable or continuable across interrupts,
   but they may not necessarily guarantee atomicity across an
   interrupt - ie. if the interrupt routine messes with the
   data structures the complex instruction is manipulating,
   atomicity may be lost.
      Simple example: what does atomicity of a block copy mean to
   you? It might mean that exactly what was present in memory when
   the instruction was first issued should be copied - which is
   seldom true (in fact, I know of RT systems that depended
   on interrupt routines being able to modify copies in progress.)
      Smaller examples, like Compare-and-swap, the processors usually
   do guarantee atomicity wrt interrupts on. But not always...

2) much more frequently, although complicated instructions may be
   atomic wrt interrupts, they are *not* atomic wrt other
   processors in the system.