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!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!aglew
From: aglew@ccvaxa.UUCP
Newsgroups: net.arch
Subject: Re: RISC question
Message-ID: <5100013@ccvaxa>
Date: Wed, 26-Feb-86 19:53:00 EST
Article-I.D.: ccvaxa.5100013
Posted: Wed Feb 26 19:53:00 1986
Date-Received: Fri, 28-Feb-86 22:07:45 EST
References: <2809@gatech.CSNET>
Lines: 23
Nf-ID: #R:gatech.CSNET:2809:ccvaxa:5100013:000:1317
Nf-From: ccvaxa.UUCP!aglew    Feb 26 18:53:00 1986


In my dabblings in RISCy architectures, I too considered non-power-of-two
instruction sizes - 12, 18, 24, and 40 bits. But I eventually surrendered
to the inevitability of powers-of-two -- being able to form memory addresses
by concatenation and simple field extraction is just so much more convenient.
After all, instructions have to be generated as data by some program.

Of course, you can always deal with funny numbers of byte sized packages,
letting the instruction fetch unit give them to you three bytes at a time,
but it is nice if every branch is at immediately addressible unit, so that
you don't have to perform any shifts before you can handle a branch.
Branches cause enough trouble as it is.

No, 32 bits is a reasonably sized instruction - after all, we're not really
worried about saving memory at the cost of speed. However, the next step up,
to 64 bits, seems a bit much, so we'll probably see a host of 32-64 bit
instruction words in the next generation. Just like in the generation before
this. But hey! there are already machines with 512 bit instructions.
Can anyone tell the net what it is really like programming on ELI(?) ?

But you know, if you decide not to be binary, powers of two don't need
to bother you so much anymore. And you've got room for an undefined value
in a decimal nibble.