Re : Re : new gcc front end question

[charfi asma <charfiasma at yahoo dot fr>]

Hi Andi,

thank you for all your explanations ;) 

what I tried to do, is to avoid the use of Flex Bison (because I did not use 
them before and they are old tools ) and I replace those tools by another which 
parse my source file and produce directly the generic form ! 

I want to pass the generic form to the gcc and I expect that he could compile it 
(i,e. when you specify the -S option, GCC will produce the .s file and will not 
link : we stop the GCC :run only cc1 not the as, the same when you specify -c we 
stop the GCC just after as we do not call ld : following this approach, I 
expected the gcc to start compiling from the Generic form ! but this is not 
possible or not implemented yet.

I will take a look at Flex Bison, since this is the only way to implement gcc 
front end.

I will bother you, of course if I get difficulties in doing that ;)

Asma



----- Message d'origine ----
De : Andi Hellmund <mail@andihellmund.com>
À : charfi asma <charfiasma@yahoo.fr>
Cc : Philip Herron <redbrain@gcc.gnu.org>; gcc-help@gcc.gnu.org
Envoyé le : Mar 14 décembre 2010, 23h 55min 39s
Objet : Re: Re : new gcc front end question

Hey Asma,
> you do not miss anything ;)
> when I call my driver "guml test.uml",  it calls the uml1.c (the compiler).
> in all other fe, the compiler (uml1.c in my case, py_lang.c for python , etc)
> calls a parser and a lexer to parse the source file, build the generic and 
then
> interface with the middle end (gimplify functions...)
>    
Yes, that's how the workflow should be in your front-end.
> so what I want to do is to tell my front end compile the new generic form 
>(which
> is a c file) every time I call you ;)
> i,e every time I call guml test.uml, the file test.c (which represent the
> Generic form) is compiled , so it is not static , it depends on the generic 
>form
> that is produced from another tool.
>    
I don't understand this either, to be honest. This is NOT how a compiler should 
work. The work done by your 'external tool' is exactly what the compiler proper 
should do. You don't need this external tool.

Unfortunately, it is also a misunderstanding that GENERIC is static, it's indeed 
NOT; the C front-end among others uses GENERIC very heavily. I don't want to 
repeat a lecture about compiler tools, but this is basically how you should do 
it, e.g. for a plus expr like 'c = a + b':

1. scanner informs parser about a new identifier 'c', parser creates/looks-up a 
VAR_DECL
2. scanner informs parser about '='
3. scanner informs parser about a new identifier 'a', parser looks-up a VAR_DECL 
(at runtime, obviously)
4. scanner informs parser about '+'
5. scanner informs parser about a new idenitfier 'b', parser, looks-up a 
VAR_DECL
6. parser/semantic logic creates a PLUS_EXPR with VAR_DECL(a) and VAR_DECL(b) as 
operands
7. parser/semantic logic creates a MODIFY_EXPR with PLUS_EXPR as single operand

All these steps are then repeated for each PLUS_EXPR, MODIFY_EXPR, etc. Finally 
such MODIFY_EXPR is put into a statement_list and the statement_list is added to 
a function which is then passed to the middle-end for further 
analysis/optimization. Though, the GENERIC construction could be completely done 
in the compiler proper. I hope it's getting clear how this should/could work.

> my problem is that the compiler itself (uml1.c) is compiled when calling make,
> so the uml1.o is fixed and evry time I call guml it uses the old uml1.o
>    
That's true and that's as expected. When thinking about a compiler, you need to 
consider that the compiler has a formal/abstract description of the language to 
be recognized (grammar) and associates certain semantic actions (GENERIC 
generation for example) with specific parts of this formal description. Once you 
have all the semantic actions implemented for all parts of your grammer, you 
don't need to re-compile each and every. It will/should then work for any valid 
input satisfying your grammer. Though, please don't recompile uml1.o each and 
every time.
> Andi suggest a solution in this post
> http://gcc.gnu.org/ml/gcc-help/2010-10/msg00293.html but I do not understand
> where should I put : " gcc my_hook.o my_generic.o<other_stuff>  -o
> <your_compiler>  "
>    
Yes, that was my suggestion, but it was meant in a different context. I wasn't 
aware of that you re-create uml1.c (or text.c) for each input file.
> In fact, I have 2 big questions:
> 
> 1. Can we add a shell command (for example execute a shell script) when 
calling
> the front end driver. If yes where should we add this command ? (this is for 
>the
> call of the other tool that produce my generic file, I want to generate Genric
> file when calling guml, it is just like the call of uml1 (the compiler) : when 
>I
> call guml, uml1 is also called, so could I execute a script whencalling guml 
?)
>    
You could obviously tell the driver to execute whatever program/shell script you 
would like to, but you shouldn't do that ;-)
> 2. In all existing front ends, when running the driver (calling the driver 
that
> itself calls the compiler) the compiler takes the name of the file and parse 
it
> (for exmple, for the python front end, it calls gpy_lex_parse( t ) that it 
>calls
> yyparse( void ) . so we did not recompile the front end , only the t parameter
> in gpy_lex_parse( t ) change, and we produce a differnet generic, gimple, ...
> In my front end, Instead of giving the name of the source file (parameter t ) 
>to
> the gpy_lex_parse to produce the genric form, I give directly the file that
> contains the generic form.
>    
This observation is true and that's how you should do it in guml. Please have a 
deeper look at the gcalc, python or any of the official GCC front-ends how this 
is implemented.

I hope that helps you to further understand the GCC front-end principles,
Andi