Re: Guidelines for instruction set design?

First of all, thank you all for your answers and your interest.
I'll try to be as clear as possible about the problem.


I'm not a compiler / system architecture expert, I'm still a student.
Remember that some things that seem basics for you might not be for
me. I'm willing to learn though.


The initial question was about wether there were instructions, design
rules or anything else that needed to be used in an instruction set if
you wanted to easily use a high level language on your CPU (ie: easily
port a compiler).


About my CPU architecture:


- 32-bits RISC, implemented in a FPGA
- Big Endian
- Multipurpose, though it has a MULAC module for signal processing
- Word adressable


- $R0..15: 32-bits general purpose registers.


- $C0..15: 32-bits "Counter" registers. They can be used to load a
constant or an address and to do indirect memory addressing. They also
support post-inc/decrementation, if you append ++ or -- to the
register name.


- $CON: a register hardwired to 0xFFFFFFFF


- $ACC: 70-bits accumulator register. It's the destination register
for MULAC operations
- $DIV: 48-bits special register holding the integer result of a div
instruction
- $MOD: 48-bits special register holding the modulus after a div
instruction


It uses a scratchpad memory, with data and instruction memory
separated.


Addressing modes:


- immediate ; I can fetch a word in the scratchpad with it's direct
address --> d(100)
- indirect ; via $C register ---> d($C0)
- $C register + offset ---> d($C0)+5




An example of instruction:


add $Cb, $Ra, $Rd
add $Cb, $CON, $Rd
add $CON, $Ra, $Rd
add d($Cb[--|++]), $Ra, $Rd
add d($Cb[--|++]), $CON, $Rd
add d($Cb[--|++]), d(Imm | $Ca[--|++]), $Rd


where:


- $Rd is the destination $R register
- Imm represents an immediate value
- d(xxx) represents a data memory access


sub, and, or, xor have the same operand constraints.


It causes me problems mainly because it's not really load store based,
like most other CPU.


- It's hard to allocate registers, for example for common
subexpression, since I can directly use memory operands.


- some memory operand are forced to some addressing modes.


eg:
I can't do add d(i), d(j), $R15
I must first load the address of i in a $C register, to indirectly
address it:


loadi i, $C15
add d($C15), d(j), $R15


- If I want to do register-register operations, I have to spill one of
the registers in the scratchpad.




I guess writing a compiler for the CPU is possible, but porting one is
much more difficult, even for retargetable compilers: most of them
make assumptions about the CPU (load/store, register based...).






About my LCC port trouble:


I've started a thread about it in comp.compilers.lcc. I'm not sure if
it's very clear though, sorry about that ; here is the link anyway:
http://groups.google.com/group/comp.compilers.lcc/browse_thread/thread/c01497f66dbc26a7#


LCC specific discussion might not be appropriate in this group and
this thread, so if you have suggestions that are specific to my LCC
trouble, please post there.






> John:
> [Interesting question. C should be pretty straightforward on anything
> with flat byte addressing and enough registers to handle stack frames.
> What makes this architecture hard? -John]


Well, yes, until then, it has been pretty straightforward, except for
one thing: handling the different register sets. It might not sound
like a problem related to the instruction set at first, but in my case
(see my LCC problem), it might be related. By the way, the CPU can
only address words. It hasn't caused me any problem so far, but well,
the work is far from done... :-)


> Ken Rose:
> I don't know anything about the poster's instruction set, but from my
> own experience, it's a pain to have to have a scratch register to spill,
> which makes a register+offset or register+register addressing mode very
> handy.


Oh yes. I've had problems to address the stack whithout a register
+offset addressing method. It was possible without it, but really
inneficient. The CPU designer and I talked about it, and he may
implement the mecanism. For the moment, I'm just assuming it is
present, to see if that kind of feature helps me or not.




> Be careful that the instruction set supports all the branches that C
> calls for. For instance, one machine I've worked on doesn't have an
> overflow flag, which makes signed comparisons awkward.


I've tested branching already, and it seems fine with what I have. But
I guess even with careful testing, you never think about all possible
inputs...




> kamal:
> Did you mean that the C compiler should be able to generate optimal
> code for the given architecture?


Well, the C compiler should at least produce good code for the
application it will used for: general purpose simple code in an
embedded system and DSP like processing with the MULAC module.
We don't want to run an OS on it or make a MIPS clone. The libc won't
be ported to it.




> If yes or even otherwise -the best
> instruction set (proven over the years) is RISC.


I've done a really quick search about this fact, but I didn't find
anything about the "best" instruction set. Can you please explain why
you say that?
From what I understand, RISC just means Reduced Instruction Set, it
doesn't imply the use of a given set of instruction, as long as your
instructions just do basic stuff.




Cyril
[RISC is a state of mind, not an instruction set design. The PDP-11 and
VAX instruction sets fit C really well, and they were anything but RISC.
(No, C wasn't designed for either of them.) -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.