This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


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

Re: Converting tm.h macros to functions




--On Sunday, June 17, 2001 07:40:56 PM +0100 "Joseph S. Myers" 
<jsm28@cam.ac.uk> wrote:

> On Sun, 17 Jun 2001, Neil Booth wrote:
>
>> I think we should have a "struct target_os" and a "struct target_cpu"
>> (I think that's all there is to being a target?) where we can define
>> stuff like this, and require targets to define them appropriately.
>> Having one or two humungous structs like this is probably not a good
>> idea, so they would need to be divided up in a logical way somehow.
>
> The problem with using structures here is that we don't want to have to
> change every back end (many more than there are front ends) when we add a
> new function (which we want to do in the most logical place in the
> structure),

I think that having one or two humongous structs is much better than what
we have now.  I was just thinking about this a few days ago.  Here is
what I would do, if I were not so lazy:

  target.h
  --------

  struct target_t {
    void (*asm_output_int) (FILE*, int);
  };

  defaults.h
  ----------

  #ifndef ASM_OUTPUT_INT
  #define ASM_OUTPUT_INT NULL

  i386.h
  ------

  #define ASM_OUTPUT_INT ix86_asm_output_int

  target.c
  --------

  struct target_t target = {
    ASM_OUTPUT_INT
  };


The advantage is that you do not have to update every target when
you add something.  You just add it to defaults.h, target.h, and
target.c.  The disadvantage is that the x86-specific functions still
have to have external linkage so that they can be initialized in target.c.

You can get around that with this fix:

  target.h
  --------

  #define TARGET_INITIALIZER \
    { ASM_OUTPUT_INT }

  i386.c
  ------

  #define ASM_OUTPUT_INT ix86_asm_output_int

  struct target_t target = TARGET_INITIALIZER;

I like this variant best, as it moves towards the direction of making
the back-end a pluggable module.

Cleaning things up in this way would be absolutely fabulous.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


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