This is the mail archive of the binutils@sources.redhat.com 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]

unifying support for TI DSP assembler emulation


Since it appears that TI uses the same core code for their 'C54x, 'C55x and 'C6x assemblers, I would like to eliminate potential code duplication by splitting gas/config/tc-tic54x.[ch] into 'c54x-specific code and generic TI assembler code (among other things, for handling bitfields and trig operations to generate constant tables).

I would like some advice on preferred ways to add additional target-specific objects to gas.

Elsewhere (in bfd) the common TI COFF code is factored out into an include file which is configured by preprocessor defines placed before the #include directive. This seems to work well with the dependency generation, but my gut feeling is that it's bad form to put C code in include files.

Another option is to add rules to gas/configure.in following the lead of m68k-parse.o and itbl-*.o. If I take this approach, then it may be difficult to customize the functions for each processor (e.g. changing octets_per_byte) in a multi-target environment. (I could pass the processor-specific bits in as parameters, but that may not be viable for some of the hook functions. Also, I prefer not to write wrapper functions that just add one parameter to a function call.)

I'm leaning towards the second option, but I'm wondering if this merits another special case in configure.in. Comments?

--
Charles Lepple <clepple@ghz.cc>
http://www.ghz.cc/charles/


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