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