aglew@ccvaxa.UUCP (03/07/86)
I've just gotten my hands on "All the Chips that Fit", and while I agree with a lot of the things Lyon and Skudlarek say, I don't agree with everything, and being the person I am I'm going to tell the net about them: "Small is beautiful" - no argument. 8bits+Parity considered useless? I find it hard to understand why they would consider the UART setting of 8 data bits _and_ 1 parity bit useless (in the Z8530). Not everybody uses 7 bit ASCII, I don't care what's in the eigth bit so I'm gonna mask it off. Not even all UNIX systems. (What I would give for a true meta key in my EMACS). Timers Time of year clock chips - I agree, I hate BCD counters; but there are one hell of a lot more digital clock radios and microprocessors controlling microwave ovens than there are UNIX systems. But maybe if we yell loud enough some chip manufacturer will start making a 128 bit long counter with 1/2^N second resolution (where N is a number appropriate to the clock frequency of your system) and an interlock to prevent the clock value from changing while you make several accesses to get the whole time. (No, I'm not kidding about 128 bits - 64 is too short for a reasonable amount of time on a nanosecond clock rate, and I've got a crush on powers of two). Multiplexed control registers (nb. not multiplexed buses - that's another story) I take great issue with L&S's attack on multiplexed chips - write as data the address of the control register you want, then access the data. They write "because UNIX is almost exclusively written in C chips at least should support a natural C language interface by allowing C structures to map directly into control and status registers". No way! Device control registers are, indeed, just like structs in C; but like a good C programmer, a good device designer should make his system extensible, so that new features can be added in the future (*). But you don't want to have to go and redesign all the boards that use the chip, just as in software we don't want to have to rewrite all the code that uses a struct when we add a field to the struct. In software we've got it easy: we just recompile everything (:-) and let the compiler move the structs around to fit; but in hardware you can't blithely increase the number of control registers assigned to a device, because boards have been laid out with the devices crammed as close together as possible, and it costs money to change them. So, multiplexed registers are the only way to go for extensible devices. Now, L&S probably don't like the idea of adding features to devices, but it is a lot cheaper to maintain one production line than several; plus, there may be advantages in designing devices to be extended gracefully, once the new features have been thought out, rather than in haphazardly reserving control registers for requirements that haven't arisen yet, since you'll probably reserve them in awkward ways. Of course, there are trade-offs here. You could take multiplexed registers to the logical conclusion, and have only two control locations, register number (written as data), and register value (to be read/written). You can safely go for one on read-only systems, but I balk at having to keep track of phase if there is only one register to be used both for addresses and read/write values. However, you pay for this in speed of access. It is probably better to put frequently accessed control registers in memory locations of their own, and infrequently accessed, or dangerous (like TURN PARITY CHECKING ON, for the Sun-1 CPU board?) behind multiplexed memory locations. No matter how many fixed locations a device uses, it should always reserve two locations for multiplexing. This is useful not only to extend chip functionality, but also for board designers - although I'm into mainly into software, I'm still proud of my 8 line multiport board for the IBM PC that took up no more space (and could replace) the standard COMn: ports, which was made possible only because the 8250 used only 7 registers. It avoided one hell of a lot of problems (shall I put this 64 byte multiport card here? - no, that conflicts with the disk driver; here? - no, it bumps into the Ethernet card; here...) The above is just like any character set or encoding - there should always be at least one escape code free. (*) True, multiplexed control registers require serializing chip accesses to avoid destructive interference. But this is true for ANY device modify cycle (store the old values, turn parity off, write them) and for any read/write transaction where you want the values of more than one register - more than can be read in one cycle on your bus. As for the most frequently used case, write a character and forget about it, look two paragraphs up - combine fixed locations and multiplexing. Timing There's been a lot of discussion about timing requirements of chips in this newsgroup, with most I'm software I don't want to know about hardware types saying that chips should enforce their delays internally by using a bus handshake. I agree with this, but point out that in a truly asynchronous system there will be a not insignificant delay before the handshake can be produced; in a multiprocessor system you're going to have to serialize access to prevent another process from sneaking in to the device. But there is no excuse for device specifications that go "How long do you have to wait between accesses? Long enough." Bravo to L&S's discussion of devices and context! Let's close off this diatribe by saying that RISCs with windows should always guarantee at least one window free for interrupt routines. What further measures can be taken to reduce the pain of process switching; who wants to save 1000 registers at every swtch? Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ...!ihnp4!uiucdcs!ccvaxa!aglew ARPAnet: aglew@gswd-vms
gnu@hoptoad.uucp (John Gilmore) (03/16/86)
In article <5100022@ccvaxa>, aglew@ccvaxa.UUCP writes: > I've just gotten my hands on "All the Chips that Fit"... > I find it hard to understand why they would consider the UART setting of > 8 data bits _and_ 1 parity bit useless (in the Z8530). Not everybody uses > 7 bit ASCII, I don't care what's in the eigth bit so I'm gonna mask it > off. Not even all UNIX systems. (What I would give for a true meta key > in my EMACS). The problem was that the chip is configurable to: 1 start bit, 8 data bits, 1 parity bit (whose value is ignored) and 1 stop bit. Nobody, I mean nobody, sends data that way; they send 1 start, 8 data, 1 stop. (One of the data bits might be a parity bit, if desired.) The chip setting only happened to work because the chip would read the stop bit as the parity bit and then, unless another character immediately followed, there was a second stop bit. (Stop bits are sent continuously until the start bit of the next character.) If you sent two chars back-to-back, it would garble them. > ...a good device designer should make his system > extensible, so that new features can be added in the future (*). But you > don't want to have to go and redesign all the boards that use the chip... > ...in hardware you can't blithely increase the > number of control registers assigned to a device, because boards have > been laid out with the devices crammed as close together as possible, and > it costs money to change them. Maybe this is true for some systems, but not the ones I've seen. Typically it's just as convenient, or more convenient, to decode high order address bits rather than low order; this puts a lot of space between the devices. This is often true because you can use a single decoder to decode up to 8 devices, each of which will vary in size -- so you pick a nice large size bigger than all of them, and decode that much space. In systems with an MMU, each device should at least have its own page, so it can be mapped separately from each other device. It's also true that very few improved chips are "drop-in" replacements in existing circuit boards. None of the various 8080 series were (8080, Z80, 8085); the 68010 was close to the 68000 but required much tighter control of the BERR* input, making it not drop in to Suns at least. The 9513A was a drop-in for the 9513, but it didn't have any extra registers either. Have any examples? > Of course, there are trade-offs here. You could take multiplexed > registers to the logical conclusion, and have only two control locations, > register number (written as data), and register value (to be > read/written). This would be almost OK. An OK chip would have the ability to read the "register number" register, so there is no hidden state, and you can use the same device from a mainline and an interrupt routine, or from two interrupt routines. (One application of this was for an NMI routine to access one timer in a 5-timer chip, the 9513, while other interrupt routines used the other 4 timers. Didn't work without major kludgery. You can't lock out NMI's, and once in a while the NMI would happen just after the register number was written but before the register value was written.) > ...I balk > at having to keep track of phase if there is only one register to be used > both for addresses and read/write values. This is unfortunately what most such chips do, and is what the authors were complaining about. > (shall I put this 64 > byte multiport card here? - no, that conflicts with the disk driver; > here? - no, it bumps into the Ethernet card; here...) This is mostly a problem because of an 8-bit I/O adress space. That 64 byte card takes 1/4 of the whole address space. That's bad I/O subsystem design, not bad I/O chip or I/O card design. -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa
jer@peora.UUCP (J. Eric Roskos) (03/18/86)
> > I find it hard to understand why they would consider the UART setting of > > 8 data bits _and_ 1 parity bit useless (in the Z8530). Not everybody uses > > 7 bit ASCII, I don't care what's in the eigth bit so I'm gonna mask it > > off. Not even all UNIX systems. (What I would give for a true meta key > > in my EMACS). > > The problem was that the chip is configurable to: 1 start bit, 8 data > bits, 1 parity bit (whose value is ignored) and 1 stop bit. Nobody, I > mean nobody, sends data that way; they send 1 start, 8 data, 1 stop. > (One of the data bits might be a parity bit, if desired.) I think what the original poster (the one with the "> >") meant was that there *are* cases in which you'd want to send 1 start bit, 8 data bits, 1 parity bit, and 1 stop bit -- except that if the parity bit's value is ignored this makes it useless. Nowadays people don't use parity bits very often for communication with terminals, because terminals tend to give a sort of visual data integrity check because they're usually run in full-duplex mode, echoing back what the user typed, so the user can see whether what was typed was what got there. (In fact, with Unix you often can't even use parity checking on a terminal if you want to, due to applications that set 8-bit mode in order to get the wakeup-on-every-character feature, and then send their data out without parity bits. Of course with System V you don't have that problem since all those parameters are separate.) So the parity bits are more likely to be useful for data transfers over serial lines. But data transfers over serial lines are usually done in 8-bit mode. So 8 data bits + 1 parity bit would be useful, as long as the parity bit was checked. Of course, that sort of data transfer is usually checked via a block check character (checksum, CRC, etc). But if you're going to have a parity bit at all, you might as well provide it for 8 data bits too. -- E. Roskos
chad@anasazi.UUCP (Chad R. Larson) (03/20/86)
In article <615@hoptoad.uucp> Jim Gilmore writes: >The problem was that the chip is configurable to: 1 start bit, 8 data >bits, 1 parity bit (whose value is ignored) and 1 stop bit. Nobody, I >mean nobody, sends data that way; they send 1 start, 8 data, 1 stop. >(One of the data bits might be a parity bit, if desired.) Not true! I have worked in many commercial systems where we had to send 8-bit EBCDIC over asynchronus lines. We always sent parity on those charaters (one start, 8 data, one parity, one stop = 11 bits). Same goes for several simple-minded binary upload/download protocols-- again 8 bit data (the bytes) with start, stop & parity. Parity, in conjuction with a longitudinal check character is pretty reliable, and doen't take as much computing as a CRC-16 (for instance). You need to be careful when you say nobody :-) -crl -- "It's not the years, it's the mileage!" -Indiana Jones _____________________________________________________________________ UUCP: {mot!terak}!anasazi!chad Voice: Hey, Chad! Ma Bell: (602) 870-3330 ICBM: N33deg,33min Surface: International Anasazi, Inc. W112deg,03min 7500 North Dreamy Draw Drive Suit 120 Phoenix, AZ 85020