Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.10 $; site ccvaxa
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!hropus!riccb!ihopa!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!aglew
From: aglew@ccvaxa.UUCP
Newsgroups: net.arch
Subject: All the Chips that (Don't) Fit
Message-ID: <5100022@ccvaxa>
Date: Thu, 6-Mar-86 21:57:00 EST
Article-I.D.: ccvaxa.5100022
Posted: Thu Mar  6 21:57:00 1986
Date-Received: Sat, 8-Mar-86 22:52:27 EST
Lines: 113
Nf-ID: #N:ccvaxa:5100022:000:6117
Nf-From: ccvaxa.UUCP!aglew    Mar  6 20:57:00 1986


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