On Thu, 16 Feb 2006, Sylvain Munaut wrote: > Move/Load/Store without flag is no problem. But for add, to allow > multiword add, carry is needed and I can't make it optionnal.
As I hinted, perhaps you can have the multiword carry a separate one from the flags carry, perhaps moved over with a separate instruction? Perhaps have a "load" variant that doesn't load; a "lea"? Perhaps it only does that when run just after a prefix instruction (that has another meaning before some other instruction)? (Look, there's your separate add and move instruction in one! :-) If it comes to that, I will go as far as suggesting that flags handling is more important than multiword add support. Really. (The latter will happen less frequently and can be performed with a few more instructions.) > But as you said, I could make the load/store take 3 args, either > load rD, rB(rA) > or > load rD, imm4(rA) > > with imm4 being between -16 and 15. That's not enough to cover a full stack frame, unfortunately. I suggest you find out a way to load an arbitrary integer into a register without touching flags (there's no point in having that touch flags) and then a way to add two registers without touching flags. Maybe it's sufficient with the first one, but I'm not willing to bet on it. > Another thing for memory. I can't make 8 bits access, the memory is 16 > bits wide and I can't change that, so 8 bits access will have to be done > in sw. That's ok. 8-bit accesses are desirable, but not a must and not as important as anything else I can think of. > Also, I could make the address given a word address or a byte address > (but then I would just drop the LSB since i don't support unaligned > access ... and the immediate in load/store would be each even between > -32 and 30). Stick with byte addresses. Really, really really. Word addresses used to be somehow supported, but there are many bugs and no other working port does it. Having the imm4 be bits 5..1 and bit 0 constant 0 is certainly the right thing to do for 16-bit-wide accesses. > Now the problem is to well describe to gcc what can be taken as an > immediate and what can't ... That's really not a problem, it's quite simple. brgds, H-P
