> The final reason are immediates. I can't have 16 bits immediates in my > opecode,
Not a problem; gcc knows how to use two insns to load immediates like that. MIPS does it. Actually, most RISC processors end up doing that. What you *would* want, though is a "load sign-extended immediate" for loading small values in one instruction. > Using 16 bits regs, do I have to support 8 bits operations on them ? At least load/save to memory. And sign extension. > > 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 ? Well, you don't *have* to if your word size is only 16 bits. GCC will still pair them, but you'll need to tell gcc how to split them back up for the opcodes you have available. Note that there are some operations that gcc assumes you have 32-bit opcodes for, though. Or at least insns that emulate it. You really want to have native support for sizeof(int) values and sizeof(void *) values, bigger things can be emulated or broken up. > 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 ... Let gcc do it then. You might end up adding a machine-specific "reorg" pass that adds a few no-ops here and there to satisfy the design rules.
