RISC 32bit instruction word -- Why not 16?! 
Author Message
 RISC 32bit instruction word -- Why not 16?!

Uh, this group is for Intel 80x86 programming, but I've added alt.lang.asm,
which should be more receptive to this type of thing, but I've also left
comp.lang.asm.x86 just to be safe (I guess).


Quote:

>    Your standard RISC cpu used a fixed length instruction work of 32
>bits.
>    I propose that it would be possible to make a RISC that uses a
>16bit instruction length.  I know some RISC people will completely refute
>my proposal, but I ask them to thoughtfully and truthfully consider my
>proposed cpu.  I understand that there be some limitations, but I believe
>the benefits would easily outweigh them.

>Benefits:
>    - nearly half the amount of memory access (commands are half size)
>            (every assembly programmer knows RAM is slow)

  I don't think so.  A 32bit architecture usually has a 32 bit data path, so
refereces to 32 bit quantities are no slower than a 16 bit reference.  And
yes, the commands are smaller, but you may end up with more commands, which
I'll get to in a bit.

Quote:
>    - code caches effectivly double size
>    - greatly reduced program size

  See above and below.

Quote:
>Proposal CPU:
>    - 16 address regs, 16 data regs
>            (address regs accessed only at full regs size)
>            (data regs in 8bit, 16bit, 32bit, or 64 bit chunks
>    - reg size up to 64 bits
>    - original implimentation need not use full 64-bit capacity

  Okay, I already see a problem.  You have quite a few number of registers
and sizes.  Now, you have 32 registers (16 address, 16 data), plus four
possible sizes for each.  Now, since you restrict yourself to one or two
operand instructions (see below), you have effectively used:

                10 bits for register addressing (5 bits for two registers)
                 2 bits for size of registers (both)
                --
                12 - leaving you with 4 bits for an instruction.

  Now, you can recover those 2 bits for sizing by having a special
instruction to set the size of the register references until the next
register resizing command, but if you do a lot of mixed size coding, you end
up wasting memory to resize instructions (16 bits).

  Now, you may be able to recover a few more bits be restricting the use of
registers.  Say, all ALU operations must be done on data registers, but
loads/store can be done to either.  So, for ALU operations you have:

                 8 bits for register addressing (4 bits per two registers)
                 2 bits for size of registers
                --
                10 bits - leaving 6 bits for an instruction, or 64
                          instructions, actually, 63 because you need one to
                          specify non ALU instructions.

  Another consideration is loading constants into a register.  I know (from
experience on the MIPS line) that to load a 32 bit constant into a register
takes two instructions (although the assmebler will take care of this for
you):

                lui     r1,#upper16     ; load upper 16 bits
                addui   r1,r0,#lower16  ; r0 is always 0

  Now, assuming only load data registers, that leaves us 12 bits left over.
We can use another 4 to specify a shift8loadimmediate8 instruction (whereby
the entire register is shifted left by 8 bits, and the remaining 8 bits of
the instruction are inserted into the lower 8 bits).  Then to load a 32 bit
constant, we have:

                ldi     d1,#$12
                ldi     d1,#$34
                ldi     d1,#$56
                ldi     d1,#$78

  There would be a similar instruction to load into the address registers.
Or, you can allow multilength instructions, but that isn't quite in the
spirit of RISC.

Quote:
>Limitations:
>    - no 3 operand commands
>            (ex: (on 386) SHRD/SHLD {shift left/right double precision})
>            (note: this is the only 3 operand command on 386)

  If you did allow three operand commands, you'ld only have two
instructions!

Quote:
>    - no more regs than proposed

  Can't have any more, no room in the instruction.

Quote:
>    - limited instuction set size (isn't that the whole concept of RISC?)

  True.

Quote:
>    The reduction of instruction size in no way limits this design to
>a 16bit cpu, it just means more instructions can be fetched in a single
>memory operation.

  Although you use more instructions.  There is no such thing as a free
lunch.

Quote:
>    Although I don't yet now a whole lot about CPU design, I do
>believe a cpu with a 16bit instruction word can be implimented.  The
>instruction set would be very tight (not much extra room for new
>commands), but that's essentially what I WANT.  If there is no extra
>space for more commands, you have obtained the most or close to the most
>compact form.

  16 bits MAY be a bit too small.  It might be managable with only 16
registers total (all general purpose) or even 8 (three bits per register,
two for size, total 8 bits.  There's tradeoffs at every point.

Quote:
>    I do not yet know all the instructions that need to be and should
>be implimented, but I'm gaining a better understanding.  Please give me
>your responses and your suggestions.

  There are such things as SISC (Single Instruction Set Computers), but
that's taking it to an extream.

  -spc (Who really really enjoys VAX assembly ... the ultimate in CISC)



Mon, 05 May 1997 13:11:29 GMT  
 RISC 32bit instruction word -- Why not 16?!


Quote:
>  -spc (Who really really enjoys VAX assembly ... the ultimate in CISC)

                                  ^^^ ^^^^^^^^     ^^^ ^^^^^^^^ ^^ ^^^^
Gack.  You're certainly right.  I know I'm always using those 6-byte
instructions that convert packed BCD to integers and destroy the contents
of 6 32-bit registers, and take like 200+ cycles to execute.

-- me (who spent one entirely-too-long semester learning VAX assembly :-)

That reminds me.  The idiotic text we used said you should always use
forward jumps, never backward, if you could avoid it. *shudder*.  I'd
rather use as many backward jumps as possible, if only to make the
assembler's task easier--I've used TASM so long I *always* specify a
distance modifier when I code jmps.  Besides, if you jump *backwards*, I
would think you'd be more likely to get code that was already in the
processor's cache.  If there are other considerations (and I'm sure there
are :) I don't know them.
--
Richard Cooley Extraordinaire           "Yeah.  Arrgh."


"LILO - it's not just a boot loader, it's a way of life" -- me



Thu, 08 May 1997 13:55:18 GMT  
 RISC 32bit instruction word -- Why not 16?!
Quote:



>>  -spc (Who really really enjoys VAX assembly ... the ultimate in CISC)
>                                  ^^^ ^^^^^^^^     ^^^ ^^^^^^^^ ^^ ^^^^
>Gack.  You're certainly right.  I know I'm always using those 6-byte
>instructions that convert packed BCD to integers and destroy the contents
>of 6 32-bit registers, and take like 200+ cycles to execute.

  Ah, well, think of it as a subroutine call where the registers aren't
saved 8-)

  But as far as structure goes, it's perhaps the most regular of instruction
sets this side of RISC I've seen.  Makes the 68K look barroque.  And I love
the fact that the PC is one of the general purpose registers.  Makes
relocatable code easy (heck, every program you write is relocatable just
about).

  But it would be interesting to see if you can get the convertion from
packed BCD to interger in under 400 cycles with the simpler instructions.

Quote:
>-- me (who spent one entirely-too-long semester learning VAX assembly :-)

  Ah, come on now.  You mean you like the Intel 80x86 assembly better?  Now
THAT was an entirely-too-long semester, especially fighting the brain dead
instructor who insisted on teaching us MASM as apposed to 8088 Assembly.
Yuck.

Quote:
>That reminds me.  The idiotic text we used said you should always use
>forward jumps, never backward, if you could avoid it. *shudder*.  I'd
>rather use as many backward jumps as possible, if only to make the
>assembler's task easier--I've used TASM so long I *always* specify a
>distance modifier when I code jmps.  Besides, if you jump *backwards*, I
>would think you'd be more likely to get code that was already in the
>processor's cache.  If there are other considerations (and I'm sure there
>are :) I don't know them.

  Gee, what possible advantage could there be for jumping forward?

  -spc (Who thought my original article didn't even make it out ... )



Thu, 08 May 1997 16:13:03 GMT  
 RISC 32bit instruction word -- Why not 16?!
see 16-bit vs 32-bit Instructions for Pipelined Microprocessors
by J Bunda, D Fussel, R Jenevin and W.C> Athas in
proceedings from 20'th ISCA conference.

They liked 16... and it was a RISC.



Sat, 10 May 1997 22:49:23 GMT  
 RISC 32bit instruction word -- Why not 16?!
:   Gee, what possible advantage could there be for jumping forward?
It makes the ASSEMBLY work a little harder, requiring 2 passes !!!
;-)

                Igx, TDD



Sat, 17 May 1997 04:22:39 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. 32bit mem range and 32bit instruction, no pmode

2. How to convert 16 bit dll to 32bit

3. 32bit vs 16 bit compile errors

4. _TEXT both defined as 16- and 32bit Segment

5. _TEXT both defined as 16- and 32bit Segment

6. 16 bits versus 32 bits instructions

7. 32 and 16 bit instructions in TASM

8. String Instructions 16 bits or 32 bits ???

9. 16 bits versus 32 bits instructions

10. 32 and 16 bit instructions in TASM

11. IN/OUT Instructions 16 bit transfers

12. Mixing 32 and 16 bit instructions

 

 
Powered by phpBB® Forum Software