RE: [cc65] assembler/C stack issue

From: Shawn Jefferson <sjefferson1shaw.ca>
Date: 2011-02-12 20:02:30
> -----Original Message-----
> From: owner-cc65@musoftware.de [mailto:owner-cc65@musoftware.de] On Behalf
> Of Ullrich von Bassewitz
>
> Oliver is completely right here: The C standard requires that chars are
> promoted to int in expressions. Doing it inside the called function is a
> size vs speed optimization, in the same way as cc65 implements "callee
> pops" instead of "caller pops" as most other C compilers do it. Having int
> promotion in the function is especially important for signed chars where
> it is much more expensive.
>
> Think about the compiler adding
> 
>         ldx     #$00
>         tay
>         bpl     L1
>         dex
> L1:
> 
> after each function call. 6 bytes including a branch - that adds up
> quickly. Especially since the function does often have more knowledge
> about the returned value and may be able to do it cheaper.

I don't know much about the C standard, thanks for setting it straight.
That makes sense.
 
> So there is nothing wrong or broken, it's just a design decision.

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.

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

Thanks!
Shawn 


----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Sat Feb 12 20:02:47 2011

This archive was generated by hypermail 2.1.8 : 2011-02-12 20:02:50 CET