mch@computing-maths.cardiff.ac.uk (Major Kano) (05/27/88)
Hi there y'all. Don't ya' jes get sick an' tired of write-only control registers and the like. (Hit 'n' if you couldn't give a 6554 status reg !) In article <1086@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >In article <253@babbage.acc.virginia.edu>, mac3n@babbage.acc.virginia.edu (Alex Colvin) writes: >>> Caching is not the only problem with I/O devices. It is (was?) >>> common practice for status registers to be cleared upon being read. >> All too common a practice! Stop it! If I'd 'a wanted it cleared I'd >> 'a done a read-and-clear! > >How many machines *have* a read-and-clear instruction? (No, the >read-and-clear must be atomic, you're not allowed to use two >instructions to do it.) Why not have writeable status registers (a la 80X87) ? Now try it like this: load cpu_reg, io_device.status_word ; clears status flags in io_device store cpu_reg, where_you_wanted_status_held ; put reg contents where you were ; going to use them in the program or cpu_reg, set_mask } ; code to operate on reg to and cpu_reg, not clear_mask } or whatever ; selectively clear or set various xor cpu_reg, not_mask } ; io_device status flag bits. store cpu_reg, io_device_status_word ; reload io_device.status_register This stops (if you want) further exceptions and leaves alone those flags you want left alone. (Intel 80X87: We don't need it anyway -- we have a NO-WAIT form ! NYAAHH ! (several ":-)"'s )) A related idiosyncracy is write-only control registers, which on various brain-damaged chips, share the (R/O) status reg addresses. Look at the BBC micro which has to keep OS copies of every control register write to the (I think) 6554. Can anyone out there who designs these things or knows more than I do (not difficult :-) say why these abominations exist or if (shock horror !) there is actually a good reason for it ? Thanks and regards, -- Martin C. Howe, University College Cardiff | "C", adj; means | I'm Motorhead; mch@vax1.computing-maths.cardiff.ac.uk. | "write-only". | Remember me now, -------------------------------------------+------------------+ Motorhead; These opinions are mine, but YOU can have them for a few $$ ! | ALL RIGHT !
stevew@nsc.nsc.com (Steve Wilson) (06/01/88)
In article <418@cf-cm.UUCP> mch@computing-maths.cardiff.ac.uk (Major Kano) writes: > > Can anyone out there who designs these things or knows more than I do (not >difficult :-) say why these abominations exist or if (shock horror !) there is >actually a good reason for it ? > One reason that most software guys are just gonna love is that I/O can be REAL expensive in hardware designs. There is usually a single path for data to exit a given logic module(board or chip), and if you have 27 local registers that are to be R/W, you've got one heck of a data funnel to create. This is a favorite place of hardware types(read me here ;-) to make design trade-offs. There really are places in the world where you WANT registers that change after you have read them. The best example I know is the common USART data register. This guy is going to have a different value everytime a new character arrives( and depending on the implementation, might actually change while software is trying to read it(Now I told that software guy he had to make his interrupt service routine faster ;-) ) Steve Wilson National Semiconductor [Universal Disclaimer goes here !]
rick@pcrat.UUCP (Rick Richardson) (06/12/88)
In article <5136@nsc.nsc.com> stevew@nsc.UUCP (Steve Wilson) writes: >In article <418@cf-cm.UUCP> mch@computing-maths.cardiff.ac.uk (Major Kano) writes: >> >> Can anyone out there who designs these things or knows more than I do (not >>difficult :-) say why these abominations exist or if (shock horror !) there is >>actually a good reason for it ? >> > >One reason that most software guys are just gonna love is that I/O can be >REAL expensive in hardware designs. There is usually a single path for >data to exit a given logic module(board or chip), and if you have 27 >local registers that are to be R/W, you've got one heck of a data funnel >to create. This is a favorite place of hardware types(read me here ;-) >to make design trade-offs. There are several common design flaws in device register architectures that, finally, the chip designers I work with are aware of and attempt to avoid. These are: 1) Write only registers, which force software types to keep a "softcopy". 2) Poor partitioning of control functions, such that one register might control both the "guzinta" and the "guzoutta" functions. The "guzinta" and the "guzoutta" software might be completely ignorant of each other (read "modular") except that they have to share this one lousy register. 3) Register bank modes where you might first have to select the register address, and then do your read/write. This forces critical regions in software. Finally, even with read/write registers in the chips, not all operations can be done with a (non-interruptible) "move", "and", or "or" instruction into the register. Sometimes you have to read the old value from the register, "and" the value with a mask, then "or" in the new control bits, and then do your write back to the control register. When you get this situation in combination with the "poor partitioning" problem, your only alternative is to shut off interrupts for this operation. Many times I've wished that the processor implemented a non-interruptable read-and-or-write instruction. Note that shutting off interrupts isn't the end of the world. However, it annoys me because the interrupt(s) you may have to shut off is for some other unrelated piece of software. Again, modularity goes out the window. In the last three years, I've had to work with no less than 8 new peripheral chip designs that went into a product design. Only 2 of those chip design teams failed to include input from the software team. Those two chip designs are the ones that have write only registers and poor partitioning. Those chips are also the only chips which have limited the software team such that some of the features that the systems engineers wanted could not be provided. At least one of our chip designers has listened so carefully to the software team that his chips regularly include bunches of creeping features. As long as he stills brings in the chip at the quoted price, I'll refrain from making the judgement on whether this is a "good thing". -- Rick Richardson, President, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 834-1378 (voice, days) uunet!pcrat!rick (UUCP) rick%pcrat.uucp@uunet.uu.net (INTERNET)
steve@edm.UUCP (Stephen Samuel) (06/16/88)
From article <510@pcrat.UUCP>, by rick@pcrat.UUCP (Rick Richardson):
=
= Finally, even with read/write registers in the chips, not all
= operations can be done with a (non-interruptible) "move", "and",
= or "or" instruction into the register. Sometimes you have to
= read the old value from the register, "and" the value with a mask,
= then "or" in the new control bits, and then do your write
= back to the control register. When you get this situation in
= combination with the "poor partitioning" problem, your only
= alternative is to shut off interrupts for this operation. Many
= times I've wished that the processor implemented a non-interruptable
= read-and-or-write instruction.
Note that the 68020 has the (new) CAS (Compare And Swap) instruction which
allows what you want. It takes 2 registers and an address: R1= old value
R2=new value address=writ location. If location != R1 then set a condition
code, else write R2 to address. Although it is meant for software interlock
it's also real good for situations like you describe where you have to do
an interlocked update of a register when a simple AND/OR/MOV won't do.
I believe that the '386 also has a similar instruction.
--
-------------
Stephen Samuel Disclaimer: You betcha!
{ihnp4,ubc-vision,seismo!mnetor,vax135}!alberta!edm!steve
BITNET: USERZXCV@UOFAMTS