Re: [cc65] assembler/C stack issue

From: Ullrich von Bassewitz <uz1musoftware.de>
Date: 2011-02-12 13:30:38
----- Ursprüngliche Mitteilung -----
> > The compiler/linker will know that the function returns a char and not
> > an int, and it shouldn't just use whatever is in A+X when promoting to
> > int, but rather "know" that it should stick a zero in X first. ??? 
> >  Seems broken if that is so?
[...]
> Certainly what you say is the normal/theoretical/native approach. What
> I describe is an optimization. Functions are supposed to be reused.
> Therefore it is desirable to place as much as possible stuff into the
> function instead at the call site. Exactly the same as with parameter
> stack handling: Theoretically the caller pushes and pops - with the
> practical benefit of having no issues with varargs etc. But for
> optimization reasons one might want to have the function pop the
> arguments.

Sorry for answering so late. I'm not at home and writing mails with the phone is somewhat uncomfortable ...

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.

So there is nothing wrong or broken, it's just a design decision.

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.
Received on Sat Feb 12 13:29:52 2011

This archive was generated by hypermail 2.1.8 : 2011-02-12 13:29:55 CET