This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi Peter,
Instead the arch I am looking at calls to CGEN, which loses me in a twisty maze :(.
Ah yes - that would be a problem. You may find that abandoning cgen and starting from (almost) scratch is an easier way to go. Ie take an existing non-cgen port, eg RX or ARM, and adapt that to your architecture. It may take a bit more work initially, but in the long run you may find it easier to mainatain.
Alternatively if you want to stick with cgen, read on...
I can see the XXX_or1k_cgen_assemble_insn in opcodes/XXX-asm.c but it calls to yet more generic code, which presumably works off the XXX_cgen_insn_table array that I can see in opcodes/XXX-desc.c. The entries are opaque to me. The "addi" entry says /* addi $rD,$rA,$simm16 */ { XXX_INSN_L_ADDI, "l-addi", "l.addi", 32, { 0, { { { load_of_flags, 0 } } } } },
Yeah, it is all table based and created by some Scheme scripts from data in the cpu/ directory.
Any idea how I can meddle with that? I can see the code in cgen.c, but it's utterly opaque to me what it consults ...
Take a look at cpu/or1korbis.cpu. It seems to me that you are going to have to replace the definition of ADDI as a normal instruction with some kind of macro instruction generating sequence. And if you can do that then you are a better man than I am Gungha Din.
Cheers Nick
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |