Re: [cc65] assembler/C stack issue

Hi!

On Sat, Feb 12, 2011 at 11:02:30AM -0800, Shawn Jefferson wrote:
> I also am not as knowledgeable in the ins and outs of compiler design as you
> are, and my naïve assumptions about what is possible are probably wildly
> wrong.  Does the compiler not know how the return value is used though?
> Whether or not the return value is used in an expression where it needs to
> be promoted to int?  I guess since the (C standard) design calls for the
> called function to make sure that a return value can be promoted to int
> safely, that you don't bother verifying this from the caller, even though
> you may be able to?  I'm not suggesting that this should be done, just
> curious if I am understanding correctly how this all works.

Actually, now I'm not sure what you mean with your question :-)

In expressions, chars must be promoted to integer. This is required by the C
standard. When a function is called that returns a char, and the function
result is used in an expression like in this example:

        extern char foo (void);
        int a, b;
        ...
        a = b * foo ();

there are two choices:

  1. the compiler could either require that foo returns the function result
     readily promoted to integer, or
  2. it can add the necessary code for the integer promotion each time the
     function is called in an expression context.

Using option 1., the generated code is usually smaller, since the necessary
code for integer promotion is added just once (inside the function) instead
each time, the function result is used in an expression. This is the reason
why cc65 does it this way.
          
Of course, the compiler does know in which context the function result is
used, and so it would also be possible to choose option 2. from above. This
would mean that each time when the function result is used in an expression,
code had to be added to do integer promotion. While this is just a load of the
X register for unsigned char, it needs the code shown in my last mail for
signed chars.

Since for option 1. the integer promotion code is executed even in cases where
the value doesn't need to be promoted to int, the code is sometimes slightly
slower. But since with option 2. integer promotion code has to be added in
many more cases, generated programs are usually larger.

So it's a size vs. speed design decision, and I've opted for size in this
case.

> The bottom line is that you had better set X to 0 when you are returning a
> char from your assembler functions.  I better check my code...

You can omit it if you do make sure it's never used in an expression. Storing
the result in a char variable is safe. But since you never know, relying on
this is usually not a good idea.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.