Re: [Liberty-eiffel] Trying to learn the C-generator....

[Hans Zwakenberg | Ocean Consulting GmbH]

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
>
>
>