DJ Delorie wrote: >> * 8 bit RISC microcontroller > > Not 16?
Well, at first it was to save space in the FPGA (basically, the regs and ALU takes twice the space) and because many 16 bits ops can be done with 8 bits regs and lots of the code I do can live with that. But I had a quick glance at the diagrams I drawed and with the modification I should do to supports 16 bits pointers with 8 bits regs, the hardware "tricks" might end up costing me more than the doubled reg banks and ALU. Another reason is speed ... I'd like to run that thing at 133 Mhz in a low cost spartan 3 ... (2 cycles per instructions so 66MIPS at the end) and a 16 bits carry chain is ... well ... longer ;) I'll do some timing test to see if it's viable. The final reason are immediates. I can't have 16 bits immediates in my opecode, there is just not the room ... (opcodes are 18 bits, the width of a classical ram-block in my FPGA technology). Do you have a 16 bits uc that fits gcc really well that I could use as a guide for the instruction set ? Using 16 bits regs, do I have to support 8 bits operations on them ? >> * 16 level deep hardware call stack > > If you have RAM, why not use it? Model calls like the PPC - put > current $pc in a register and jump. The caller saves the old $pc in > the regular stack. GCC is going to want a "normal" frame. This is > easy to do in hardware, and more flexible than a hardware call stack. Well that solution isn't that easy with 8 bits regs and the 16 deep stack is the same a a single register in the FPGAs I use. But now, with 16 bits regs, it might simplify this and that may become a better solution. >> * 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. > > GCC is going to want register pairs to work as larger registers. > Like, if you have $r2 and $r3 as 8 bit registers, gcc wants [$r2$r3] > to be usable as a 16 bit register. Another reason to go with 16 bit > registers ;-) > > GCC won't like having an address split across "special" registers. > > But it's OK to limit index registers to evenly numbered ones. So If I use 16 bits registers, do I have to handle pairs of them to form 32 bits ? 16 bits regs keeps sounding better and better ... I know HDL better than gcc so if it can ease the gcc port at the cost of a slightly bigger/more complex HDL design, I'm willing to make the trade-off. >> * 2 flags Carry & Zero for testing. > > GCC will want 4 (add sign and overflow) to support signed comparisons. > Sign should be easy; overflow is the carry out of bit 6. Shouldn't be much of a problem to add that. >>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 ? > > Delay slots are common; gcc handles them well. You might need to add > custom code to enforce the pipeline rules if your pipeline won't > automatically stall. Yes, making the pipeline stall isn't easy in my case and detecting those case will costs me logic and decrease my timing margin. The hardware detects that the preceding instruction writes in a register read by the current instructions and forward the results. But for memory fetch (and io access), there is just no way, the results appears too late ... Sylvain
