liberty-eiffel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Raphael Mack
Subject: Re: [Liberty-eiffel] Trying to learn the C-generator....
Date: Fri, 15 Aug 2014 19:45:04 +0200

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 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]