This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [gas] new port advice
- From: Peter Breuer <peter dot t dot breuer at gmail dot com>
- To: Nicholas Clifton <nickc at redhat dot com>
- Cc: binutils at sourceware dot org
- Date: Tue, 14 Apr 2015 00:02:55 +0100
- Subject: Re: [gas] new port advice
- Authentication-results: sourceware.org; auth=none
- References: <20150407164700 dot 4f8023ed at betty dot enbd dot org> <552549DC dot 4050805 at redhat dot com> <20150408213050 dot 5220b130 at betty dot enbd dot org> <5526848C dot 9020506 at redhat dot com>
- Reply-to: Peter dot T dot Breuer at gmail dot com
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