#24 inefficient code one way, incorrect code another

closed-out-of-date
4
2013-05-25
2000-10-03
No

I fear that part of the problem is that the dataflow analysis code is somehow flawed, but I have tried everything (except standing on my head while typing) to get around this. Here's the commented code:

/*

All of the following comments are with respect to SDCC 2.2.0a.

The following code shows the creation of an unnecessary temp to compute
the problem expression #1 marked below.

If the type of the variable d2 is "extern data unsigned long", the
generated code (correctly) does not need a temp.

If the type of the variable d2 is "extern data unsigned short", the
generated code (incorrectly) thinks it does need a temp.

Even worse, if the expression is coded as "d0 = d1 + d2 + (a0 >> 9);",
then the argument needs to be put in a temp as well!

However, if expression #2 is coded the "correct" way:
return ((xdata unsigned long*) &xa0[0])[l0];
then variable l0 requires the temp, but its high byte is ignored(!),
and the calculation in expression #1 is as I would expect.

I don't know if the intervening function calls are involved, but since my code requires them, I've left them in.

*/

extern data unsigned long d0;
extern data unsigned long d1;
extern data unsigned short d2;
extern xdata unsigned char xa0[1024];
extern void f1(void);
extern void f2(void);
extern void f3(void);

unsigned long f0(unsigned long a0)
{
unsigned short l0 = a0 & 0x7f;

d0 = (a0 >> 9) + d1 + d2; /* #1 */
f1();
f2();
f3();
return *((xdata unsigned long*) &xa0[l0]); /* #2 */
}

Discussion

  • Marty Shannon

    Marty Shannon - 2000-10-03

    Oops, forgot to mention that the invocation of sdcc in this case is simply "sdcc -c tst.asm".

    Oh, yeah, 10 points to whoever figures out what the code is really trying to do! :-)

    Marty

     
  • Marty Shannon

    Marty Shannon - 2000-10-03

    Urk! Make that "sdcc -c tst.c"!

     
  • Johan Knol

    Johan Knol - 2001-07-01

    Logged In: YES
    user_id=63512

    Because d2 is a short (as for now 8bit) is requires a cast
    to long in expression #1

    Because l0 is a short (as for now 8bit) it has no high byte.

    So, although this may not be optimal, I don't see anything
    wrong with it.

    Johan

     
  • Johan Knol

    Johan Knol - 2001-07-01
    • priority: 5 --> 4
    • assigned_to: nobody --> johanknol
     
  • Johan Knol

    Johan Knol - 2001-08-01
    • milestone: 100100 --> non_bugs
    • status: open --> closed-out-of-date
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks