I record here the stream support of some computer architectures I have worked with. In particular I report the hardware designed to turn streams into memory arrays and back. I will describe these systems: The heaviest use of each of these facilities was probably for streams of characters and today’s byte addressing has supplanted the heaviest work of these three schemes. Yet there are other advantages to the old streaming ideas.

Functionality

PDP-10

Actually there was a series of machines from DEC with this architecture: PDP-6, PDP-10, KA-10 and perhaps others. This describes the byte pointer structure and machine instructions that manipulated that structure. I cannot improve on the description found there but I note that characters did not span words. It was fairly easy to increment a pointer by n bytes; the hardware did not do this but it could have if it had become important. Likewise the number of characters between two characters could be easily computed. This scheme did no buffering and the bytes were promptly moved to or from memory.

An interesting proposal would have been to allocate two words per pointer and make the new word an assembly register. Most writes via a pointer would be a one word split cycle memory access. (This assumes that there was room in the instruction for the bits/byte value.) As it was built two split cycles, or four complete cycles were required for an IDPB instruction.

This architecture abstracts away from the code byte size, but not string length. It does not buffer.

Burroughs B5500

There is much detail in the above reference that I have not digested.

Stretch Index Registers

The 64 bit index registers held three fields: bit address, count and refill value. Many instructions included micro-instructions such as increment, increment and count, or increment-count and refill. The increment was the address field in the instruction which was added to the address of the index register. (This is sometimes called ‘progressive indexing’.) The count option decremented the count in the index register. The refill option would locate a new 64 bit value for the index register to be used when the count went to zero. I am not aware that the refill field was used in practice.

Harvest Index Units

The Harvest was preeminently a streaming machine and while streaming no conventional instructions were obeyed. There were two index units to read streams from memory, and one to write a stream back. Memory addressing was to the bit. While conventional instructions could not participate in streamed data, there were about 20 miscellaneous special stream units that consumed and produced streams. These units could be ‘programmed’ to work together by control fields fetched from memory when streaming started.

Bytes might span word boundaries. An index unit took its instructions from core memory. There were 128 bit patterns that I will call ‘instructions’ here. (‘Index control words’ in the original) One instruction might be to fetch (or store) a sequence of n bytes at stride s each of b bits per byte. A byte pointer, which was part of the index unit state, would thus be incremented by ns bits. When finished the following instruction was obeyed. Another instruction was to loop back to a designated previous instruction and decrement a count that was kept in the instruction proper. When that counter reached zero the index unit proceeded to the next instruction instead of looping. The count in the instruction was refreshed from another field in the instruction. This instruction included a pointer increment. Refreshing a counter value could come immediately from the loop instruction, or indirectly from a count value in the instruction of an outer loop command. Thus triangular arrays of various sorts were supported.

The harvest index units provided the full list of functions described above under “Functionality”.

more