new gcc front end question

[Andi Hellmund]

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