Design a microcontroller for gcc

[Sylvain Munaut <tnt at 246tNt dot com>]

Hello,


I'm currently considering writing my own microcontroller to use on
a FPGA. Since I'd like to be able to use C to write
"non-timing-critical" parts of my code, I thought I'd include a gcc port
as part of the design considerations.


I've read the online manual about gcc backend and googled to find
comments about gcc for microcontroller and I found that thread
particulary interesting :

http://gcc.gnu.org/ml/gcc/2003-03/msg01402.html


Here is a small description of the type of microcontroller I'm thinking of :
	* 8 bit RISC microcontroller
	* 16 general purpose registers
	* 16 level deep hardware call stack
	* no special instruction or regs for the stack
	* load/store to a flat "memory" (minimum 1k, up to 16k)
	  (addressing in that memory uses a register for the 8 lsb and
           a special register for the msbs)
	  that memory can be loaded along with the code to have known
	  content at startup for eg.
	* classic add/sub/... have 3 registers operand (dest,src1,src2)
	* no hardware mul, nor shift-by-n (have to be done in software)
	* pipelined with some restriction on instruction scheduling
	  (cfr later)
	* a special "I/O" space (gcc shouldn't care, we should only
	  access it in asm)
	* relative short/long call/branch, absolute short/long
	  call/branch. (The long branch/jump are achieved by preloading
	  a special GPR with the MSBs to use for the next jump)
	* 2 flags Carry & Zero for testing.
	
	

(note these are not random choices, I know how I can implement that in a
FPGA quite efficiently ...)

My first question would be : "Do you see anything that's missing that
would be a great plus ?"

I mentionned earlier that there is some scheduling restriction on the
instructions due to internal pipelining. For example, the result of a
fetch from memory may not be used in the instruction directly following
the fetch. When there is a conditionnal branch, the instruction just
following the branch will always be executed, no matter what the result
is (branch/call/... are not immediate but have a 1 instruction latency
beforce the occur). Is theses kind of limitation 'easily' supported by
gcc ?

I saw several time that gcc works better with a lot of GPRs. I could
increase them to 32 but then arithmetic instructions would have to use
the same register for destination than for src1.

eg. for the add instruction,  I'm planning :

add rD, rA, rB		; rD = rA + rB
add rD, rD, imm8	; rD = rD + immediate_8bits

but if I allow 32 registers, my opcode is too short so I have to limit :

add rD, rD, rA		; rD = rD + rA
add rD, rD, imm8	; rD = rD + immediate_8bits

I'm more in favor of only 16 registers because :
 - Some uc have even less and have working gcc
 - 16 is already a good number
 - 16 uses less space in the FPGA ;p
 - I'd rather have the possibility to store result elsewhere than have
32 registers.

But maybe I'm wrong ...



Any comments, thoughts, ... are welcomed !



	Sylvain