Path: utzoo!utgpu!water!watmath!clyde!att!alberta!calgary!radford
From: radford@calgary.UUCP (Radford Neal)
Newsgroups: comp.arch
Subject: Re: More On Write-Only Control Registers
Keywords: read-only write-only
Message-ID: <1697@vaxb.calgary.UUCP>
Date: 23 Jun 88 01:38:18 GMT
References: <439@cf-cm.UUCP> <22150@amdcad.AMD.COM> <2007@alliant.Alliant.COM>
Organization: U. of Calgary, Calgary, Ab.
Lines: 41

In article <2007@alliant.Alliant.COM>, steckel@Alliant.COM (Geoff Steckel) writes:

> ... in order to save some complexity in the 11/04 CPU, DEC had
> made the MOV instruction ALWAYS READ ITS MEMORY DESTINATION.  This meant that
> 	MOV	Rn, OUTPUT_REGISTER
> would first read (and discard!) the top of the input FIFO.
> 
> There was absolutely nothing that could be done to make this combination of
> CPU and peripheral work...

I'm not sure which was more brain-damaged - the 11/04 for reading the
destination, or the peripheral device for placing the read-only and
write-only registers at the same address. 

Lest anyone think the above poster's experience was unique, I had a 
rather similar problem with a Motorola 68008 and an Intel timer chip
(I forget its number). The timer chip required that one write the
two bytes of the time interval to a register _with no intervening
accesses_. The C code to do it was something like:

     *reg = 100; /* Low-order part of time interval */
     *reg = 0;   /* High-order part */

Unfortunately, the compiler (quite reasonably) implemented the last
statement with a CLR instruction, and the 68008 (and 68000) does
a CLR by first reading the destination...

This only took about an hour to debug, since I had a hardware person
with a scope on the bus lines to help in debugging (this was an 
embedded application in ROM - no debugging tools). I shudder to 
think how long it could take to find this sort of problem in another
context, or with a less experienced programmer.

The fact that the 68000 reads the destination of a CLR I find rather
boggling. The performance penalty alone would seem to be enough to
rule this out - particularly since they had the option of leaving the
CLR out alltogether if it was that much of a problem, since this was the
first processor of that architecture. Reading the destination on
_every_ move in the 11/04 is far worse, of course...

    Radford Neal