Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site bmcg.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!bmcg!bprice
From: bprice@bmcg.UUCP
Newsgroups: net.arch
Subject: Re: Arbitrary byte alignment
Message-ID: <1433@bmcg.UUCP>
Date: Wed, 10-Oct-84 14:48:49 EDT
Article-I.D.: bmcg.1433
Posted: Wed Oct 10 14:48:49 1984
Date-Received: Thu, 11-Oct-84 08:09:08 EDT
References: 
Reply-To: bprice@bmcg.UUCP (Bill Price)
Organization: Burroughs Corporation, San Diego
Lines: 34
Summary: 

In article  John Levine, ima!johnl writes:
>I suppose it would be possible to have fiendishly clever memory designs
>where adjacent words were always in different memory banks so you could
>cycle both at the same time.  Sounds pretty awful, though, since you have
>to determine for each memory reference how many memories to cycle and how
>to splice the parts together.  As far as I can tell, it's never been
>seriously proposed for implementation, except perhaps incidentally in very
>large cached architectures such as the IBM 308X.

Indeed, it has been done.  The Burroughs B1700-B1800-B1900 series had a memory
of two banks, interleaved by word.  If the word containing the first address
were in bank A, it was fetched.  At the same cycle, bank B was accessed with
address n or n+1, as appropriate.  As I recall, the words were 32 bits.  The
processor's data path was 24 bits, so many possibilities arose:  all bits
in the same word; all bits in two words, but in one processor word; the operand
in two memory words, and two processor words;...

There were several features of the B1700 architecture that were noteworthy--the
bytes that we all know and love, that we are discussing here--the B1700
addressed bits, and operand sizes were given in several levels:  address
granularity in the code, "byte" size for string operations, string length.  The
processor was microcoded, and several interpreters were provided: COBOL-RPG,
Fortran, and MCP (the operating system), were the most popular.  Interpreter
selection was dynamic--the operating system used a different one than the
programs did, quite often.  The microcode had a dedicated memory, and the size
of the microstore was the subject of a hardware option:  it ranged from zero to
nearly enough.  Overflow microcode resided in main memory.

Enough for now.  Maybe somebody who knows more about the B1700 could carry on.

--Bill Price
-- 
--Bill Price    uucp:   {decvax!ucbvax  philabs}!sdcsvax!bmcg!bprice
                arpa:?  sdcsvax!bmcg!bprice@nosc