This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
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