Re: Target-specific Front-Ends? (Was: front end changes for

[Aldy Hernandez <aldyh@redhat.com>]

>>>>> "Ziemowit" == Ziemowit Laski <zlaski@apple.com> writes:

 > On Tuesday, November 27, 2001, at 06:23 , Aldy Hernandez wrote:

 >> I've actually thought about implementing generic front end extension
 >> support to gcc for this kind of nonsense.  Sort of like a preprocessor
 >> that runs after the actual C preprocessor-- massages the output in any
 >> way it sees fit, and feeds its output to the lexical analyzer.
 >> 
 >> This way if someone wants to implement some brain dead front end
 >> extension widely used somewhere else, it could be a plugin-- and we
 >> could offer a whole slew of plugins in the future (altivec plugins,
 >> msoft inline assembly plugin, etc etc).
 >> 
 >> That sounds like a good project :)

 > Well, it definitely sounds interesting!  Tell me more. :) :)

simple, it just reads the output from CPP, manipulates the strings,
and, feeds it's output to the lexer.

You would register your extension before the lexer starts doing it's
thing.

Code is worth a thousand words:

        typedef char * (*fe_extension)(char *);

        char *
        altivec_extension (char *line)
        {
                char *p;

                p = altivec_massage (line);
                return p;
        }

        void
        lexer_setup()
        {
                ...
                if (TARGET_ALTIVEC)
                        register_fe_extension (altivec_extension);
                ...
        }

        int
        lex ()
        {
                ...
                c = extended_lexer ();
                ...
        }

        int
        extended_lexer ()
        {
                char *p;
                static char *q;
                int i;

                if (!q || !*q) {
                        p = read_next_line ();

                        /* Massage the current line with all the FE
                           extensions applicable.  */
                        for (i = 0; i < total_fe_extensions; i++)
                                q = (fe_extension[i])(p);
                }

                return *q++;
        }

that's the general idea.  The assumption is that most FE extensions
can be translated into something saner involving intrinsics or
something more gcc-able.  The goal is not to provide an entire parser
in each extension, but to come up with a set of heuristics that will
do string replacements.

In cases where we need context, the extension could keep a few state
variables to know what it's seen so far and what it expects.  Nothing
too complicated, just to get the job done.

One simple example would be for the altivec extension to recognize

        ...(1,2,3,4)

in an initializer and merely replace it with {}'s.

...and I'm taking volunteers for this project :)

Aldy