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
