[sdcc-devel] [ sdcc-Feature Requests-1669851 ] compares could be more compact

[SourceForge.net <no...@so...>]

Feature Requests item #1669851, was opened at 2007-02-27 11:35
Message generated for change (Comment added) made by maartenbrock
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1669851&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Frieder Ferlemann (frief)
Assigned to: Nobody/Anonymous (nobody)
Summary: compares could be more compact

Initial Comment:
/* compares are a relatively common used operation.
   Especially the signed compares could probably
   be more compact.
 */

unsigned int myint_u;
  signed int myint_s;
unsigned char mychar_u;
  signed char mychar_s;

bit b;

void main(void)
{
  /* unsigned int compare currently is:
        clr     c
        mov     a,_myint_u
        subb    a,#0x34
        mov     a,(_myint_u + 1)
        subb    a,#0x12
        jnc     somewhere$

     and probably could be:
        mov     a,_myint_u
        add     a,#(0x10000-0x1234)
        mov     a,(_myint_u + 1)
        addc    a,#(0x10000-0x1234)>>8
        jc      somewhere$
  */
  if (myint_u < 0x1234)
     b = 1;


  /* unsigned char compare is fine:

     mov     a,#0x100 - 0x12
     add     a,_mychar_u
     jc      somewhere$

  */
  if (mychar_u < 0x12)
     b = 1;


  /* Could signed compares be handled by checking the
     alternate carry flag AC?

     mov     a,#0x80 - 0x12
     add     a,_mychar_s
     jnb     AC,somewhere$

     instead of:

     clr     c
     mov     a,_mychar_s
     xrl     a,#0x80
     subb    a,#0x92
     jnc     00106$

  */
  if (mychar_s < 0x12)
     b = 1;

  /* And:

        mov     a,_myint_s
        add     a,#(0x8000-0x1234)
        mov     a,(_myint_s + 1)
        addc    a,#(0x8000-0x1234)>>8
        jnb     AC, somewhere$

     instead of:

        clr     c
        mov     a,_myint_s
        subb    a,#0x34
        mov     a,(_myint_s + 1)
        xrl     a,#0x80
        subb    a,#0x92
        jnc     somewhere$

  */
  if (myint_s < 0x1234)
     b = 1;


  /* "<" is probably used most often but
     likewise for "<=", ">", ">=" */
}


----------------------------------------------------------------------

>Comment By: Maarten Brock (maartenbrock)
Date: 2007-10-30 17:18

Message:
Logged In: YES 
user_id=888171
Originator: NO

Frieder,

The AC flag is for internal carries from bit 3 to bit 4. I think you meant
the OV flag. And its value should be inverted when changing subb to add,
just like jc/jnc for unsigned.

To David (merc64) and 'Nobody': The compiler already is very modular in
this sense and you can even add peephole rules without recompiling the
compiler itself.

Maarten

PS. Double-posting isn't nice either.

----------------------------------------------------------------------

Comment By: David Barnett (merc64)
Date: 2007-03-21 20:22

Message:
Logged In: YES 
user_id=896846
Originator: NO

It's not nice to hijack people's RFE's =).

I agree that the basic features themselves and the optimizations should be
separate since many people would like to add optimizations without
affecting the existing functionality, but I think they already are pretty
modularized.  There's a peephole optimization system that does
target-specific optimizations based on special peephole files, but probably
not many RFE's have been about peephole optimizations.

I haven't done any development on sdcc yet, so forgive me if I'm wrong on
some of this, but...  AFAIK, sdcc parses the input files into a syntax
tree, all global optimizations happen on the syntax tree, and then the
back-end translates the syntax tree into the appropriate target language. 
Since a lot of complexity goes into the source->AST and AST->target
conversions, there's not much happening in the optimization section but
optimizations.  If you understand the AST and know where in the control
flow the optimizations happen, then it should be easy to add more
optimizations.  That said, I haven't figured all of that out myself.  Maybe
when and if I do I can document it all more thoroughly so more people can
develop optimizations.

Please post any further comments that aren't specifically related to
Frieder's RFE to the sdcc-devel list instead.

David

----------------------------------------------------------------------

Comment By: David Barnett (merc64)
Date: 2007-03-21 17:49

Message:
Logged In: YES 
user_id=896846
Originator: NO

It's not nice to hijack people's RFE's =).

I agree that the basic features themselves and the optimizations should be
separate since many people would like to add optimizations without
affecting the existing functionality, but I think they already are pretty
modularized.  There's a peephole optimization system that does
target-specific optimizations based on special peephole files, but probably
not many RFE's have been about peephole optimizations.

I haven't done any development on sdcc yet, so forgive me if I'm wrong on
some of this, but...  AFAIK, sdcc parses the input files into a syntax
tree, all global optimizations happen on the syntax tree, and then the
back-end translates the syntax tree into the appropriate target language. 
Since a lot of complexity goes into the source->AST and AST->target
conversions, there's not much happening in the optimization section but
optimizations.  If you understand the AST and know where in the control
flow the optimizations happen, then it should be easy to add more
optimizations.  That said, I haven't figured all of that out myself.  Maybe
when and if I do I can document it all more thoroughly so more people can
develop optimizations.

Please post any further comments that aren't specifically related to
Frieder's RFE to the sdcc-devel list instead.

David

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-03-21 17:09

Message:
Logged In: NO 


Browsing through the various RFEs here, it seems that a good portion
of feature requests is related to potential optimizations, either
generic ones, or target/situation-specific ones.

While I would personally feel quite capable of addressing some of
these optimization proposals, I currently lack however the familiarity
with the sdcc sources, as well as the spare time required to get
familiar with the sources as a whole.

So, I was wondering whether some modularization in this area
might help, that is:
I would like to know whether anybody else has previously
considered, implementing optimizations in a separate, possibly
even standalone fashion, decoupled from the actual compiler itself?

Basically, this would seem to boil down to factoring out the code
that takes currently care of optimizations, so that it may become
a separate entity (common code may still be shared using a lib).


Of course, one would need some way to allow the C compiler frontend
and such a standalone optimizer to communicate with each other,
however this could be as simple as dumping internal data structures
into some intermediate format (temporarily), which in turn may be
dealt with by the optimizer (possibly using a tiny library with API
hooks for exactly this purpose).

Optimizations themselves could then be implemented by providing
"plugins" (or modules) for the standalone optimizer.

That way, the sdcc suite as a whole would become more modularized
and it would become easier for people to contribute in this area,
without having to know anything else beyond the optimizer-related
code. Eventually, contributors would be able to implement most of
the more trivial optimizations on their own, by querying the AST/ASG
of the C source program and issuing the proper low level (i.e.RTL/ASM)
instructions (FWIW, on the gcc mailing lists, there were repeatedly
discussions related to providing "scriptable" optimizations).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1669851&group_id=599