This is the mail archive of the 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]

Re: [gas] new port advice

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]