old processor architectures [was Re: The Strange Birth and Long Life of Unix - IEEE Spectrum]

[James Knott]

D. Hugh Redelmeier wrote:
> There are costs to this design.  The bus has to work for the slowest
> peripheral AND the fastest RAM.  The bus has to support a lot of
> fan-out/fan-in.  The semantics of reading or writing memory is somewhat
> different from the semantics of reading or writing a device register.
> Precious chunks of address space are lost (but a notional instruction bit
> is gained).

I worked on a variety of systems.  IIRC, they all used the same bus for 
I/O and memory.  Also, back in those days, core memory was used, which 
was slower than I/O registers.

> I/O instructions didn't have indirection.  So if you wanted the same
> code to handle multiple devices, you had to build the instruction
> dynamically, probably as self-modifying code (in other words, probably
> within the instruction stream).

Actually, in a lot of hardware, such as serial ports, where you'd have 
multiple lines etc., there was a register to select which line you 
wanted to access and then the same I/O address was used as for all other 
lines.  The Data General line had only 64 device codes (I/O addresses).  
Yet, you could run multiple disk & tape drives and hundreds of serial 
ports, with the serial ports spread over multiple boards.  With disk 
drives, the device code was 20 for the primary controller and 60 for the 
secondary.  You could then select one of the drives attached to that 
controller.  Mag tape was 22 & 62 IIRC, again you could select one of up 
to eight drives.  Same again with disk pack drives (30 & 70?) etc.  If 
all that wasn't enough, you could add up to 4 Data Channel Adapters, 
each of which was a chassis that included a single board Nova, for 
controlling all the I/O in that chassis.  On the other hand, DEC used 
the "Unibus", which daisy chained through all the chassis, controllers, 
memory boards etc.  Finding a fault somewhere on that Unibus could be 
"interesting".  I worked on some Data General Eclipse systems that had 
multiple drives, a DCA and a few hundred serial ports.

> The PDP-11 had a stack, recognized in hardware, and certainly in the
> description of the hardware.  It was one of the first to have that
> (certainly Burroughs machines had stacks about a decade earlier).
>
> The PDP-7, PDP-8, and the Nova did not.  The Nova architecture was
> later extended to have a stack (infered from the page you mentioned
> <http://users.rcn.com/crfriend/museum/doco/DG/Nova/base-instr.html>).

As you say, the Nova didn't have a stack, but the Eclipse did.

> | I guess it was 2 instructions, not one.  With the above, if the "Done" flag
> | was set, you'd skip over the next instruction and execute whatever followed.
> | If it wasn't set, you'd jump back the NIO instruction and run it again.
> | However, IIRC, you could do a JMP .0, which would loop on that single
> | instruction.  The "." made it a jump relative instruction.
>
> All non-indexed, non-page-zero jump instructions were relative.
> Assembly notation might disguise this.
>
> The "." means current location in DG and DEC assemblers.  Assemblers
> generally allow fairly complex assembly-time expressions in operands.

I think we're saying the same thing.  The . means relative to the 
current location i.e. -1 the previous location.  The I/O flag status 
tests resulted in either a .2 or .1, to skip or not depending on status.

> The PDP-8 CPU was reimplemented in a single chip quite
> early and probably could have killed off the 8080 if DEC hadn't been
> scared that it would have killed off their mini business
> <http://en.wikipedia.org/wiki/Intersil_6100>.

There were also microprocessor versions of the PDP-11 and Nova.  The 
LSI-11 was used in some Heathkit computers and also the boot loader 
(loaded the microcode into the CPU) of the VAX 11/780 systems.  The Nova 
CPU was used in the DCAs mentioned above.






--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists