|
From: | Hans Zwakenberg | Ocean Consulting GmbH |
Subject: | Re: [Liberty-eiffel] Trying to learn the C-generator.... |
Date: | Sat, 16 Aug 2014 16:01:20 +0200 (CEST) |
Hi Rapha,
thank you for your step-by-step explanation of how to get to know the compiler system better. I do have many more questions! Having said that, your answer has shown me that I should dig into the Eiffel language itself before following up on all the warning messages the C-compiler throws out, as much of what you point out is still over my head. Back to the drawing board...
Thanks again!
Hans
> Raphael Mack <address@hidden> hat am 15. August 2014 um 19:45 geschrieben: > > > Hi, > > I don't know the C generation part at all, so please, Cyril correct me > where I'm wrong. Here is what I'd do (and did, just out of curiosity): > > - take a look at compile_to_c.id (you need to compile "compile_to_c" > from eiffel source to generate it, as it is not checked in in the germ) > - search for "T351", "T706", and "T789" > - see, that all three classes are expanded infer from this, that the C > backend generates se_cmpTxxx functions to compare expanded values. > - look at the classes, their attributes and their implementation of > is_equal (consider inheritance) > - see, that the class CLASSES_TREE_FACTORY (that with the strange > is_equal code) has only one interesting attribute, (file_tools: > FILE_TOOLS) - which itself has no interesting attributes -> it is not > very interesting to compare instances of FILE_TOOLS and therefore also > not for CLASSES_TREE_FACTORY. The implementation returns always "the two > exapanded values are different", which is ok in my eyes. > > And yes, they are really dead code -> we could add a ticket, that in > case the program under compilation, doesn't compare values of some > expanded class, the cmp-function should not be emitted. > > Any more questions? > > Rapha > > Am Freitag, den 15.08.2014, 16:52 +0200 schrieb Hans Zwakenberg | Ocean > Consulting GmbH: > > Hi Group, > > > > as an exercise for me to get to know the C-code emitter better: > > > > Consider the following three functions that are present in > > compile-to-c1.c: > > > > int se_cmpT351(T351* o1,T351* o2){ > > int R=0; > > R = R || ((o1->_mangling) != (o2->_mangling)); > > return R; > > }/*--*/ > > > > int se_cmpT706(T706* o1,T706* o2){ > > int R=0; > > return R; > > }/*--*/ > > > > int se_cmpT789(T789* o1,T789* o2){ > > int R=0; > > R = R || ((o1->_hashed_string_memory) != > > (o2->_hashed_string_memory)); > > R = R || ((o1->_column) != (o2->_column)); > > R = R || ((o1->_line) != (o2->_line)); > > return R; > > }/*--*/ > > > > Clearly se_cmpT706() is breaking the mold set by the other two > > functions, i.e. it's doing nothing productive (and the compiler justly > > complains about the two function arguments not being used). I guess > > at least three scenarios are possible: > > - the function should be kept as perhaps it is being called by other > > code, even if it does nothing, in which case the existence of this > > function is merely justified by avoiding error messages > > - the function should have been optimised away alltogether > > - the function should really do a comparison, and the code the > > C-emitter generates is at fault > > > > My concrete question: where do I look in the Eiffen and C sources to > > determine which of the above assumptions is correct? > > > > cheers > > Hans > > > |
[Prev in Thread] | Current Thread | [Next in Thread] |