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]

Re: [gas] new port advice


On Thu, 09 Apr 2015 14:54:20 +0100
Nicholas Clifton <nickc@redhat.com> wrote:
> 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.

Gunga Din says it need not be done that way.

The structure of md_assemble in tc-XXX.c is

  md_assemble(char *str) {
    XXX_insn insn;
    /*0*/ gas_cgen_init_parse();
    /*1*/ insn = XXX_cgen_assemble_insn(.. str, ...);
    /*2*/ gas_cgen_finish_insn (insn, 32, ...);
  }

and *1* is a parse of the incoming ascii assembler line (str) to some
insn struct and *2* is a pretty print of the insn struct as machine
code.

So between *1* and *2* one gets the opportunity to do some rejigging
when the right sort of instruction turns up.

An addi is whapped into a new shape, for example, by rewriting every
field in sight in the insn struct to something that looks right for
what it should end up as. If it works, it works.  Continue until it is
so.

The addi is prefixed by other instructions by putting between the 
*1*/*2* pair another parse-print pair:

   pre_insn1 = XXX_cgen_assemble_insn(...  mystr1 ...);
   gas_cgen_finish_insn(pre_insn1, 32, ...);

and repeat for as many prefix instructions as wanted.

The cute thing is that the target addi has already been parsed and that
grabs for the parser a label from the assembler file (if it had one) and
all the prefixes now get the same label, as the label is changed in the
parser's state only when a new label is met.  That's the only
significant bit of statefulness I noticed in the parse. Thank goodness
it's simple - if it is.

So the XXX_cgen_assemble_insn call is pretty much independent (I
think the jargon is `re-entrant') each time, so one can call it as one
likes on the assembler strings one makes up any old way. And machine
code gets emitted from gas_cgen_finish_insn.

The horribleness is that I have no idea what fields of insn are really
significant either for the printer or for whatever the parser remembers
or might do next.  Oh for a document.  Still, it works, seemingly.


PTB


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