#198 compares could be more compact

open
nobody
None
5
2007-02-27
2007-02-27
No

/* 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 "<=", ">", ">=" */
}

Discussion

  • 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).

     
  • David Barnett
    David Barnett
    2007-03-21

    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

     
  • David Barnett
    David Barnett
    2007-03-21

    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

     
  • Maarten Brock
    Maarten Brock
    2007-10-30

    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.

     
  • Logged In: YES
    user_id=589052
    Originator: YES

    > ... I think you meant the OV flag. And its value should be inverted ...

    Yes, that was meant. Thanks for having a look and also thanks for
    implementing request #1750727 !)