Re: unifying support for TI DSP assembler emulation

[Nick Clifton <nickc at redhat dot com>]

Hi Charles,

> 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.

Agreed.

> 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.)

You could have a global structure that contains the architecture
specific information and which is accessed from the TI-generic code.

You could initialise this structure in md_begin() based on the value
of TARGET_CPU, and you could even provide assembler pseudo ops to
change the settings if you want to support multi-architecture
assembler source files.

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

I think it does.

Cheers
        Nick