lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) (08/23/89)
While I'm on the subject of knowing what one's system is, and does: In article <9786@alice.UUCP> jmk@alice.UUCP (Jim McKie) writes: > The timer is both readable and writeable, and the > counting function is controlled by the low three bits, which are > write only. Oh, dear. Write only registers, again. This used to be an extremely common practice in device interfaces, and in most of the early LSI. It was aften a royal pain. The offending designers usually come back with "but you set it! Just remember what value you set it to!". This is a lousy answer. The value may be wrong because the algorithm that sets it needs debugging. The value may be wrong because we (or someone else) didn't understand the !@#$& manual. This was particularly likely when a mode could only be established through some sequence of writes, rather than through a single write. The value may be wrong because the chip is wrong. Leaving aside the sad history of "sample" chips, there have always been production chips on the market with more-or-less obscure design bugs. The value may be wrong because the software was interrupted. The value may be wrong because there are multiple masters. I have sad memories of an intelligent terminal whose modes could be adjusted by its operator. The handler software couldn't know he'd done it, and couldn't ask the hardware what its modes were. This was software running on pure faith. (Actually, it would have been running on faith, except that we never got it running. By the time we understood the !@#$& manual, the terminal had croaked.) The value may be set by software which is attempting to restore a previous mode. (The classic sequence is: sample mode: change mode: compute: restore previous mode. I will leave aside the famous problem of getting interrupted just after the sampling step.) In this case, the "but you know what you set it to!" comeback is a statement that the software is monolithic. Why should I have to communicate values to the corners of the earth? Why can't I write the clear, easy-to-prove routine that samples/sets/restores? -- Don D.C.Lindsay Carnegie Mellon School of Computer Science
mmm@cup.portal.com (Mark Robert Thorson) (08/24/89)
This discussion of write-only bits reminds me of an occassion when I was helping somebody bring up software for a prototype Unibus frame buffer. He had written some simple code to scribble on the frame buffer, just to see if it was working and to verify he knew how to address it. That code worked fine. Then he had written some more advanced code to support a decent demo program. That code didn't work at all. He finally localized the bug to an XOR instruction being used to actually perform the write to the frame buffer. It seemed as though XOR didn't work. "Maybe the XOR instruction is broken," I said. "That's impossible, the operating system uses XOR. Nothing would run if it were broken." he said. "Well can't you at least try replacing that XOR with something else?" After much desperation trying other things, he did that. He read the frame buffer, did some operations on it in register, and wrote it back out. To his utter amazement, that worked fine. After a few seconds of thinking about it, I said, "You know, a read cycle and a write cycle on the Unibus are different from a read-modify-write cycle. There's a code on the control lines which indicates a DATIP cycle." (DATIP is DEC parlance for data-in-pause, which is same as an RMW operation. This was used for faster access to destructive-read core memory by inhibiting the write-back of the read data.) It turned out that the hardware engineering group had not implemented DATIP cycles, figuring that read and write are enough.
hjm@cernvax.UUCP (Hubert Matthews) (08/24/89)
Read-Modify-Write cycles can be really nasty. I cannot remember which particular PDP-11 stuff it was, but one of the character I/O devices had the read and the write port at the same address; read the address and you get the next input character, write it and that character goes down someone's line. This is fine until someone changes the spec. for the CPU so that the microcode always did RMW cycles. "Why do I lose an input character whenever I do a write?". This took a long time to find, and a lot of cash to solve (buy completely new peripherals, ugh). So, please, no more write-only registers or similar gate saving tricks. -- Hubert Matthews ...helping make the world a quote-free zone... hjm@cernvax.cern.ch hjm@vxomeg.decnet.cern.ch ...!mcvax!cernvax!hjm
henry@utzoo.uucp (Henry Spencer) (08/25/89)
In article <21547@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: >(DATIP is DEC parlance for data-in-pause, which is same as an RMW operation. >... >It turned out that the hardware engineering group had not implemented DATIP >cycles, figuring that read and write are enough. Major mistake, and not just because of R-M-W instructions. Even some operations you would think would be straight writes were done with RMW on some Unibus CPUs. (I can remember being very surprised to discover that a byte clear, I think it was, on an 11/45 was doing RMW on its destination.) -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
roy@phri.UUCP (Roy Smith) (08/25/89)
In article <1063@cernvax.UUCP> hjm@cernvax.UUCP (Hubert Matthews) writes: > So, please, no more write-only registers or similar gate saving tricks. My impression of Unibus read-only and write-only registers sharing the same address was that it wans't meant to save gates, but address space. On a Unibus, you only have (if I remember correctly) 4K of I/O space and that space was sparsely used, in an effort to make auto-configure possible (i.e. if there is something at address 77XXXX, it must be a YY-11). With 32-bit address spaces common today, this is probably not necessary. In a sense, DEC did the same with their pdp-11 opcodes; "add byte" was really "subtract word". Given the confines of a 16 bit word, I suspect they did the right thing, but again, it's probably not necessary today. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network"
dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) (08/25/89)
In article <21547@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: >Then he had written some more advanced code to support a decent demo program. >That code didn't work at all. He finally localized the bug to an XOR >instruction being used to actually perform the write to the frame buffer. >It seemed as though XOR didn't work. I once had the same experience. I had to clear the interrupt level for some disk controller. As this particular operating system (called ERM System) was written in C, I used the quite normal C expression: cntrl->int_lvl = 0; which was compiled (for a MC68008, :-) to the instruction: clr.b 0xF(a4) which seems quite normal. The register however was write only. Somehow I continuously kept on having bus errors for this one. I did expect that a CLR instruction writes a 0, but after having read the small print, I discovered that the CLR was implemented as an XOR (i.e. read-modify-write). -- Dolf Grunbauer Tel: +31 55 432764 Internet dolf@idca.tds.philips.nl Philips Telecommunication and Data Systems UUCP ....!mcvax!philapd!dolf Dept. SSP, P.O. Box 245, 7300 AE Apeldoorn, The Netherlands
slackey@bbn.com (Stan Lackey) (08/25/89)
In article <1989Aug24.221628.11330@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Major mistake, and not just because of R-M-W instructions. Even some >operations you would think would be straight writes were done with RMW >on some Unibus CPUs. (I can remember being very surprised to discover >that a byte clear, I think it was, on an 11/45 was doing RMW on its >destination.) Yes, CLR is encoded in with a bunch of instructions that rmw a dest, like INC, ROT, etc., and it was easier to use the same control flow and just substitute a 'generate zeroes' ALU operation. CLR was not considered a performance issue. If you needed a CLR that did just a write, you did a MOVx #0,dest. -Stan