jeffj@sfmin.UUCP (J.S.Jonas) (03/11/86)
From postnews Fri Feb 28 18:09:19 1986 Subject: Re: RISC question Newsgroups: net.arch References: <2809@gatech.CSNET> <9921@amdcad.UUCP> > 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 systems using ROM code could have a 13 bit instruction length and 32 bit address/data length. The instruction data path could be separate from the data path (instruction in 13 bit wide ROM, data in 32 bit wide RAM), or the data lines could be used (just ignore the upper bits). Yes, there will be two memory systems, but if you're running separate I/D space that's not news to you. 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)). 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. I recall that a single bit processor (I don't remember the number) had a 4 bit instruction but 1 bit data/registers (flags really), so instruction size != data size. The PC was external to the chip. Jeff 'just thought of it' Skot {ihnp4 | allegra | cbosgd} attunix ! jeffj
tim@ism780c.UUCP (Tim Smith) (03/15/86)
> I think that the instruction length can be different. A dedicated >systems using ROM code could have a 13 bit instruction length and >32 bit address/data length. The instruction data path could be Have you ever worked for General Instruments? :-) -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
rb@ccivax.UUCP (03/19/86)
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 :-).