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@xxxxxxxxxxxxxxxx> À : charfi asma <charfiasma@xxxxxxxx> Cc : Philip Herron <redbrain@xxxxxxxxxxx>; gcc-help@xxxxxxxxxxx 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
