Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!bu.edu!encore!jcallen
From: jcallen@Encore.COM (Jerry Callen)
Newsgroups: comp.arch
Subject: Re: Living With Old Baggage
Summary: Some baggage is useful (compare and swap)
Keywords: 68040 CAS2
Message-ID: <14628@encore.Encore.COM>
Date: 22 Apr 91 15:37:16 GMT
References: <336@scorpio.gtephx.UUCP> <12741@pt.cs.cmu.edu>
Reply-To: jcallen@encore.Com (Jerry Callen)
Organization: Encore Computer Corp, Marlboro, MA
Lines: 37

In article <12741@pt.cs.cmu.edu> lindsay@gandalf.cs.cmu.edu (Donald Lindsay) writes:

>[regarding 68020 instructions that Moto had to carry over to the 68040]
>
>An example they weren't able to dump was "cas2". This fetches two
>independant words, and then conditionally overwrites them, with one
>big R/M/W lock on memory during the whole 4 memory cycles.
>
>Since each of these words could be unaligned, there could be four
>page faults just in fetching them.

cas2 is a horrible case of overkill, but a "reasonable" compare and swap
instruction would be AWFULLY handy. By "reasonable" I mean an instruction
that:

- fetches an aligned word from memory
- compares it to a register
- if the values match, the value in another register is stored back
- a condition code is set somewhere that indicates whether or not the
  store was done.

The ancient IBM 370 offered essentially this instruction; the OS used it
extensively, and I used it to implement locks at user level. It was 
sure handy!

Yes, this is VERY complex by RISC standards, but it makes a number of
nasty synchronization problems almost trivially easy. You can sorta-kinda
emulate compare and swap using test and set (which the 88K has) and spin
locks, but to do so in complete safety you have to disable interrupts
(nasty from user code...).

What makes a "reasonable" compare and swap so hard to implement that
current RISCs don't do it? It seems to me that implementing test and
set already forces MOST of the hard work to be done anyway.

-- Jerry Callen
   jcallen@encore.com