Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!ittatc!dcdwest!sdcsvax!sdcrdcf!hplabs!qantel!lll-lcc!lll-crg!gymble!umcp-cs!seismo!rochester!ritcv!ccivax!rb
From: rb@ccivax.UUCP
Newsgroups: net.arch
Subject: Re: address != data != instruction length
Message-ID: <490@ccivax.UUCP>
Date: Tue, 18-Mar-86 18:40:28 EST
Article-I.D.: ccivax.490
Posted: Tue Mar 18 18:40:28 1986
Date-Received: Sun, 23-Mar-86 00:20:47 EST
References: <670@sfmin.UUCP>
Reply-To: rb@ccivax.UUCP (What's in a name ?)
Distribution: net
Organization: CCI Telephony Systems Group,  Rochester NY
Lines: 68

In article <670@sfmin.UUCP> jeffj@sfmin.UUCP (J.S.Jonas) writes:
>> In article <2809@gatech.CSNET>, dana@gatech.CSNET (Dana Eckart) writes:
>> > I can not think of a "good" reason why 24 bit architectures are not
>> > used instead.
>> >                        Have we surrendered to 32 bits without a "good"
>> > reason?
>> The reason that 32-bit architectures are so popular is addressing
>> range:  a 32-bit address space is nice and big (for now at least)
>> but a 24-bit address space is too small.  Since the CPU has to
>
>	Why do you equate address length with data length with
>instruction length?  I know that addresses are handled as data, so if
>the address length = data length, then registers can hold an
>entire address (unlike the 8088/6 with 16 bit registers and 20 bit address).
>[okay, the address can be any length after the MMU is through with it
>since the CPU has no access to the bus address].
>
>	I think that the instruction length can be different.  A dedicated
>system using ROM code could have a 13 bit instruction length and
>32 bit address/data length.
>
>	Now say you want a system with loadable programs.  Will you
>need a 13 bit-word disk for programs and a 32 bit word disk for data?
>No, you could put the instructions in the data space either unpacked
>or packed.  How about this - the instructions are packed in data
>memory (you could put 2 instructions per word with 7 bits wasted,
>or try to span words (yeccch)). 

This is done with 2900 and other bit-slice processors and is suitable for
microcode internal to the chip, but could cause problems if this was the
exterior archetecture.

The main reason for the 8/16/32/64 is that
1: bit widths that are powers of two are easier to calculate.
2: 8 bits is the smallest power of 2 which can support a full alpha-numeric
character set (many would consider this insufficient).

consider the 24 bit instruction.  Prime factors are 2 * 2 * 2 * 3.  Powers
of two are simple shifts, but powers of 3 are shift and add, requiring
a second register and an additional cycle.

To do a "computed case" statement, you would have to use B=A; A<<1; B=B+A.

You would also have a bit more trouble insuring your compiler maintained proper
alignment.  With 16/32, this can be done with a simple AND of the least
significant bit(s).   24/48... alignment requires a true modulo computation.

You can get around these problems with microcode or software, but the
trade-offs in terms of cost and execution time don't seem to be worth it.

If you want a good example, try running some array manipulations and
computed calls with 48bit (6 byte) structures through your C compiler
and compare the timings with 64bit (8 byte) structures.  I've actually
seen code "optimised" by simply padding a structure to a larger size.
(To be fair, this was on an 8085 machine where the multiply routine
only did the add if there were more than to "on" bits in one of the
multipliers)

If you come up with a neat new way to do *3 or any other small prime number
in 1 cycle, let me know :-).

>The instructions are read into
>cache where they are unpacked as needed.  Reading 2 instructions
>per cycle seems attractive to me.  This then eliminates the need
>for two memory systems.
>
This is a good idea (maybe) it might be fun to try if 64 bit archetectures
(or even 16 bit instructions on 32 bit arch's) become popular :-).