[ih] Intel 4004 vs the IMP

[Brian E Carpenter]

I told a lie. The PDP-11/20 did have priority interrupts, and
the Unibus was intrinsically capable of DMA. So it probably
could have done the IMP job, had it been on the market
a year or three earlier. But you needed an 11/45 to do any
real multiprogramming with memory management.

Regards
    Brian
On 16-Nov-21 14:11, Brian E Carpenter wrote:
> As late as 1973, I believe you still had to go up the Digital
> range as far as a PDP-11/45 to get multiple levels of interrupt
> priority, so that a high priority interrupt could interrupt
> processing of a Teletype interrupt, for example. Honeywell
> was well ahead of that game. (As was an IBM 1800, but that had
> ten times the footpriint.)
> 
> I never touched a 4004, but as far as I can see it only had CPU-
> controlled 4-bit I/O ports, with neither interrupts nor DMA. It
> would have been a busy little bee trying to do an IMP's job.
> 
> Regards
>      Brian
> 
> On 16-Nov-21 11:54, Jack Haverty via Internet-history wrote:
>> True for more modern systems, but in the era of the 316/516, inexpensive
>> computers sometimes did I/O in the simplest possible manner.  E.g., to
>> handle I/O on a serial interface, the CPU might have to take an
>> interrupt on every byte, read that byte from the hardware interface, and
>> re-enable the interface quickly enough for it to be ready to handle the
>> next byte,   The hardware only buffered a single byte at a time.  The
>> CPU also had to do that all fast enough to handle all the streams of
>> interrupts from all its interfaces in order not to lose data.   That
>> would occur if a particular line received a byte and raised its
>> interrupt, but the processor was too busy handling other interrupts and
>> didn't get to that one before the next character had assived on the
>> serial line. It got worse of course as line sppeds were increased.
>>
>> That's how a PDP-8/I I worked with in 1968 worked.   I think 
that kind
>> of issue is the one Alex referred to about selecting the 316 because of
>> its interrupt mechanism.   Since the IMP was essentially a multi-port
>> I/O handler, how the hardware handled I/O on all those interfaces was a
>> crucial factor in selecting the 516.   That's why I suggested
> that the
>> I/O capabilities of a microprocessor needed to be considered when trying
>> to figure out how it compared to the 516, more so than just classic
>> metrics like raw memory and CPU speed. About ten years ago I dug into an
>> early version of the IMP code to figure out how it worked.   
The main
>> CPU was essentially an interrupt processor, waiting in an idle loop for
>> an interrupt to occur and then handling it fast enough to avoid not
>> getting to the next interrupt fast enough to avoid losing any data.
>>
>> As machines matured and costs dropped, hardware interfaces became
>> smarter and could process large chunks of data for each interrupt.
>> Essentially the interface contained a "co-processor" that offloaded the
>> main CPU.  I don't recall how the earliest micros handled interrupts and
>> I/O, but that's why it's important to look at the I/O capabilities for
>> Steve's question.
>>
>> /Jack Haverty
>>
>>
>> On 11/15/21 1:53 PM, Noel Chiappa via Internet-history wrote:
>>>        > From: Jack Haverty
>>>
>>>        > IIRC, another of the important criteria for selecting the Honeywell 516
>>>        > was the I/O performance characteristics
>>>        > ...
>>>        > So in looking for the earliest "comparable" microprocessor, in
> addition
>>>        > to comparing metrics such as CPU speed and memory, I think you
> have to
>>>        > look at I/O characteristics
>>>
>>> Yes, but... in a _router_, the CPU didn't need to _ever_ look at most 
of the
>>> data in the packet. In anything that did TCP, yeah, you had to do the
>>> checksum, and that almost always needed the CPU to fondle each byte, but in
>>> e.g. the CGW, since it _never_ copied packets around (not even e.g. to
> make
>>> room for a longet physical network header on the front), if a packet came in
>>> one DMA interface, and out another, the CPU never even saw most of thwe bytes
>>> in the packet, so the CPU speed was not too relevant, it was all bus-bandwidth
>>> dependant.
>>>
>>> Early on, not all network interfaces were DMA; there were three different
>>> approaches:
>>>
>>>     - DMA
>>>     - full packet buffers in the interface, but the CPU had to manually
> move
>>>       bytes from the interface to buffers in memory, so 3 bus cycles/word (with
>>>       unrolled loop with pointers to device and buffer in registers i)
>>>       instruction fetch, ii) read from interface, iii) write to memory)
> so 3
>>>       times as much bus traffic per word, compared to DMA
>>>     - interrupt per word
>>>
>>> But even the latter wasn't _necessarily_ a problem; at MIT, the main ARPANET
>>> gateway for quite a while used the Stanford/SRI 1822 Interface:
>>>
>>>      https://gunkies.org/wiki/Stanford_1822_Interface
>>>
>>> which was interrupt/byte, but peformance wasn't a problem (that I recall).
>>>
>>> Like I said, for all early routers, performance was not an issue. Performance
>>> only became an issue when there were multiple COTS router vendors, when
>>> performance became an easy way for their marketing people to distinguish their
>>> products from those of competitors. I doubt the users could ever have 
told.
>>>
>>>
>>> I don't know if _early_ microprocessors (i.e. long before Motorola 68Ks, Intel
>>> x86's, etc) supported DMA on theit memory busses; even for those that 
didn't,
>>> it might have been possible to build an external bus controller, and either
>>> stall the CPU (if the memory bus was busy doing DMA), or build a multi-port
>>> main memory, or something.
>>>
>>>         Noel
>>
>>
>