Path: utzoo!mnetor!uunet!husc6!mailrus!ames!necntc!ima!johnl
From: johnl@ima.ISC.COM (John R. Levine)
Newsgroups: comp.arch
Subject: Re: Do RISC Compilers Consider Multiprogramming?
Message-ID: <1002@ima.ISC.COM>
Date: 4 May 88 19:25:18 GMT
References: <620@speedy.mcnc.org> <10707@steinmetz.ge.com>
Reply-To: johnl@ima.UUCP (John R. Levine)
Organization: Not much
Lines: 41
Keywords: RISC compiler context-switch architecture multiprogramming

In article <10707@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>  Interesting thought from the past... the GE 600 series allowed
>interrupts on an instruction fetch from an even location (since the bus
>was 72 bits wide that was every other instruction). This resulted in the
>ability to preserve context throught a few instructions.
>
>  What are the ramification of doing the same thing on a newer
>processor? ...

Actually, each 635 instruction had a LOCK bit that let you write
interrupt-proof sections as long as you wanted, subject to a lockup timer that
would blow you away after a few milliseconds. User mode (a/k/a slave mode,
ugh) programs could do this as well as the system. But I don't think that
either the LOCK bit or the instruction pairing locked out memory accesses by
any of the other processors, making the lock bit of only moderate use in
most systems which contained multiple CPUs.

Modern processors don't have a LOCK bit because they have better uses for
their instruction bits. These days you can get the same effect by preceding
your locked section by an "interrupts off" instruction and following it with
an "interrupts on" instruction. This is adequate to implement critical
sections on uniprocessors but not on multiprocessors. On multiprocessors it
seems to be useful to write code sort of like this:

	interrupts off
	set global lock in memory	; typical special instruction
	... manipulate locked structure ...
	release global lock
	interrupts on

You turn off the interrupts to make sure that the global lock is not held an
unduly long time because an interrupt occurs in the middle. The manpulation is
usually only a handful of instructions, so it's quicker to wait for someone
else to release the lock than to do any sort of queueing to wait for it.

(It's more complicated, if you can't get the lock right away you have to
turn interrupts back on while you wait, but I'm sure you get the idea.)
-- 
John R. Levine, IECC, PO Box 349, Cambridge MA 02238-0349, +1 617 492 3869
{ ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something
Rome fell, Babylon fell, Scarsdale will have its turn.  -G. B. Shaw