This is the mail archive of the cgen@sources.redhat.com mailing list for the CGEN 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: binutils porting to new CPU


Hi -


>  [...]
> Do you have a more detailed API description of what is generated and
> how it should be used for porting the binutils? [...]

There isn't a really good list, I'm afraid.  None of those who have
built a complete port took the extra time to document all the steps
and nuances.  It's all rather vernacular: start based on an existing
port, do a massive search & replace for a new port name, ask here when
you run into trouble.  A simple port may go smoothly enough not to
need any help.


> Also gas/cgen.c contains code for fixups and parsing. How does all
> this fit into the big picture of porting binutils to a new cpu target?

It's a necessary detail.  The fewer addressing modes your target supports,
and the simpler the layout of the operands that parametrize any given
address, the simpler (to almost nonexistent) these functions can be.


> How do fixups and frags ??? fit into the API? [...]

They barely do.  Some CGEN operand parsing functions plop fixups into
the assembler, for ultimate disposition as an assembly-time constant,
or emission as a link-time relocation.  Frags are little
partially-filled-in byte strings that are concatenated ultimately
to form object code.  All this is deep GAS/BFD magic, not really cgen
related.


- FChE

Attachment: pgp00000.pgp
Description: PGP signature


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