Re: [cc65] __fastcall__

From: Alan Cox <>
Date: 2015-01-15 12:12:16
> - The linker config allows a "bank ID" to be appended to a code segment (segments that are in the same bank have the same bank ID).

Yes, the linker seems to be well prepared for that part

> - The compiler keeps track of this bank ID, and if it calls a function in another

The compiler doesn't know it. The code is generated before the linker
ever touches it.

Likewise even if the compiler did know about it you are still allowed
function pointers and tables of functions. For that to work you need
stubs and to be able to identify a function by a 16bit value not a
24bit one

> Not sure how complicated that is to make those changes on the cc65 side.

I actually don't think cc65 is affected at all - other than perhaps to
verify that if you tell it you are generating banked code there are no
__fastcall__ functions perhaps.

> something like that maybe?  If you leave it up to the user to define the banking routine, any banking scheme or hardware can be supported.  We could develop code to support the common ones.

Something like that. The shortest sequence I can see that wouldn't be
too messy would seem to be

__stub_func_x: lda #<func_x
                       ldx #>func_x
                       jmp _via_page_1  ; or _2 etc

which is 7 bytes and so about the same as jsr helper; .word func_x,
rts; but faster than having the page function have to play stack

I guess most 'via_page_n' functions would end up doing

;  Entry: X,A = pointer in bank, Y to be preserved (arg count in
varadic function calls)
                        sta ptr1
                        stx ptr1+1
                      [ Get the old bank into A ]
                      [ Set bank n ]
                        call jmpptr1
; Function return may be in X,A and also _sreg and _sreg+1
                        tay           ; save A part of return
                      [ Set old bank ]
jmpptr1:            jmp (ptr1)
To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Thu Jan 15 12:12:23 2015

This archive was generated by hypermail 2.1.8 : 2015-01-15 12:12:25 CET