This is the mail archive of the gcc-patches@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: RFA: TARGET_PTR_TO_C_LEX


>>>>> "Zack" == Zack Weinberg <zackw@stanford.edu> writes:

    Zack> Wouldn't it be simpler to add a dummy c_lex function to the
    Zack> Java and Fortran front ends, which just aborted?

Using function pointers is the ideal solution to this kind of problem,
when there isn't too much concern about performance.

The reasons are several:

  - Pieces of the compiler (front-end or back-end) don't have to
    change if they don't care -- they just use the default value of
    the function pointer.

  - One front-end (like C++) that is related to another (like C) can
    use the other front-ends version.  For example, C++ can do its
    thing, and then call the C version of the function.  You can't
    do that with magically named functions because you can't have
    two functions with the same name in the same program.
    
  - Some day, it would be really cool to build the various chunks of
    the compilers as plug-ins, and have a single struct full of 
    pointers that was the interface between chunks.

In fact, long-term, it would be good to rely on macros much less
heavily in the target machine files.  Obviously, there are some places
where function call overhead is prohibitive, but there are others
where it probably isn't.  (A lot of the TM files thunk to functions
from those macros anyhow, but the programs are harder to debug, and
the oddities of the C preprocessor come into play.)

My two cents,

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