Re: [cc65] __fastcall__

From: Ullrich von Bassewitz <uz1musoftware.de>
Date: 2015-01-14 14:23:49
On Tue, Jan 13, 2015 at 04:10:35PM +0000, Alan Cox wrote:
> The basic idea would be to spot any calls to a banked function from a
> function not in that bank and instead of relocating the JSR address
> replace it with a JSR to a stub where any target the first time it is
> found gets a stub generated that is something like

It is no big problem to generate the stubs from within the linker. But there's
additional information necessary to know in which bank a subroutine lives.
Getting this right and configurable in a general way seems quite a task for
me.

Idea: There's already a ".BANK" pseudo function in the assembler that allows
to access an attribute assigned to a memory area. If the compiler generates
code like

        jsr     switcher
        .byte   <.BANK (_realroutine)
        .addr   _realroutine

for a call to the external function _realroutine, the switcher function in
common memory could at runtime determine if a bank switch is necessary or not.
Advantage is that no changes to assembler and linker are necessary, drawback
is that all such calls have a runtime overhead. If later support is added in
compiler, assembler and linker to mark these snippets in a special way, the
linker could rewrite the ones where no bank switching is necessary as

        jsr     _realroutine
        nop
        nop
        nop

to avoid most of the runtime cost.

Maybe you have ideas for simpler solutions. All bank switching ideas that have
been discussed so far have been found to be quite some work.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
Encrypted email preferred                          PGP Key-Id: 29D93B10
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Wed Jan 14 14:23:54 2015

This archive was generated by hypermail 2.1.8 : 2015-01-14 14:23:56 CET