Re: Converting tm.h macros to functions

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

Joseph S. Myers wrote:-

> How should a target indicate that it has its own version of one of
> these functions?  Should a macro be used (e.g., defining
> HAVE_asm_output_ascii to indicate that the target has its own
> asm_output_ascii function and the default one should not be compiled
> in)

I don't think so.

> or should function pointers be used, initialised to the default
> function and changed (where?) by the back end to point to the
> back-end-specific version?

I'm interested in this too.  If we want to replace specs, we need a
similar way to have target functions linked into the driver, to handle
some of the conditional logic that specs are currently handling.

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.

Configury can define macros for Makefile.in so that the object files
can be linked in easily with MAKE variables like ${target_os} and
${target_cpu}.

In other words, I think you should have function pointers, with a NULL
meaning "not interested" if this is meaningful for the function in
question, much like the hooks stuff I did in toplev.h
(e.g. post_options() can be NULL).  The default functions should be
exported and be collected in a header file so that the target files
can include it, and use the defaults if they want, or maybe override
the defaults and possibly call the default later (like inheritance in
C++).

I think something along these lines is much cleaner than hundreds of
target macros.  It would put in a few structures everything that is
required if you want to add a target O/S or target CPU - simply supply
the relevant structure with all fields filled in.

toplev.c's DEBUG handling is a conditional compilation mess IMO, which
could be really cleaned up by using function pointers instead.  In
fact, that would enable removal of some of the debug callbacks from
toplev.c, like debug_define(), that are only relevant to the C front
ends: c-lex.c could call the various debug handling functions through
pointers itself rather than deferring to toplev.c to multiplex for it.

At least, that's my take on these things.  I don't know all the nitty
gritty, so I might be missing some things.

If you could set up the beginnings of a framework for this, that would
be cool; it would make replacing specs a lot easier and less
disruptive.  Thoughts?

Neil.