Re: [C--] bool and bits1

 > Yes, After reading Dias' dissertation, I realize that an optimal 
 > front-end for C-- is not to simplify  complex expressions if it's not 
 > neccessary. But simply simplifying all complex expressions are much 
 > easier to implement.   I guess I'm probably not the only one does so.  

Sure.  For example, lcc does it, and we have a back end for C--.

 > > If your front end insists on simplifying boolean expressions, than
 > > your front end should compile them as lcc does, to conditional branches.
 > >
 > >  > 1. Why there is no bool type in the C-- grammar, but the semantics of 
 > >  > C-- has bool type? allowing bool type would eliminate the above 
 > >  > redundant  type conversions.
 > >  > 
 > >  > 2. I guess most of the use of bits1 is like the above case.  Any 
 > >  > exception?  Why bool and bits1 are not equivalent types?
 > >
 > > bits1 is for values and bool is for control flow.
 > > They are handled differently in the back end.
 > >   
 > bool type is not uncommon in high level programming languages.  How does 
 > it map to a C-- type?  Without bool type in C--, a bool type has to be 
 > converted to bits1 and then convert back later.

It depends whether the bool type is used in a value context or a
control-flow context.  In my front ends, a boolean in a value context
is compiled to bits32 and a boolean in a control-flow context is
compiled to control flow.  But that's because I'm interested in
polymorphic languages where every value is the same size.  How you
compile Booleans is really your choice; the point is that there are no
Boolean registers on modern machines, so there are no Boolean
*variables* in C--.  There are only Boolean *expressions*, and these
may appear only in control-flow contexts.


Norman
_______________________________________________
Cminusminus mailing list
[email protected]
https://www.eecs.harvard.edu/mailman/listinfo/cminusminus