On Wed, 11 Sep 1996, der Mouse wrote:

: Are there no 68k family CPUs that can interrupt partway through an
: instruction?  I know some VAX instructions are interruptible, but the
: 68k doesn't have the monster instructions like MOVTUC the VAX does.

The 68k has no interruptible instructions native to the CPU itself,
excepting perhaps some extensions found in the 68040+ (is MOVE16
interruptible?).  Coprocessor (particularly FPU) instructions may or may not
be interruptible; take a gander at the 'busy stack frame' spit out by the
FPU by a FSAVE when one such instruction is interrupted. 

The 68k has a couple special instructions which go even a bit further than
the uninterruptible instruction dogma; look at CAS and CAS2 (sigh, we lost
the latter in the 68060), which use a 'read-modify-write' cycle--that is,
data is read, possibly modified and written back, all in one uninterruptible
cycle.  That makes CAS the perfect 'check and modify' instruction for a
semaphore or other mutually exclusive lock in a multitasking system.

: > There is another way to avoid spl* calls in these situations:  All
: > you need to do is store your binary flags each in a char variable.
: 
: > 	union {
: > 		int ssir_int;
: > 		char ssir_c[4];
: > 	} ssir;
: 
: > Then you can "set a bit" by just slamming 1 into one of the char
: > slots.  In this case, you can even check four values at one time in
: > the service routine (though that will need an spl).
: 
: _May_ need an spl, depending - you don't always need to lock around
: such accesses, depending on what you're doing and which pieces of code
: can interrupt which other pieces.
  ...
: The ability to store a single char as a single uninterruptible
: operation without reading and rewriting at least one adjacent char (and
: of course without explicitly locking out interrupts) is inherently
: machine-dependent....

I hate to think interrupts should ever need to be locked out in such
situations, but you're right in that not every processor is uninterruptible
like this.  And then again, the compiler may not even decide to compile it
that way.  (It might decide to do a BTST followed by BSET/BCLR for one bit
of this on a m68k; that's certainly interruptible.)  Given that this code is
running in supervisor mode, if code spawned by interrupts doesn't access
this data, no lock worries.  If the point is to worry about interrupts...
<cringe>

=====
== Todd Vierling (Personal tv@pobox.com; Business tv@iag.net) Cast a vote! ==
== System administrator/technician, Internet Access Group, Orlando Florida ==
== Dialups in Orange, Volusia, Lake, Osceola counties - http://www.iag.net ==