RE: [cc65] __fastcall__

From: Shawn Jefferson <sjefferson1shaw.ca>
Date: 2015-01-15 04:21:57
I've been doing a cartridge based project, and banking is relevant there too.  If I were to envision how this would work in my simple view, I'd envision this:

- 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).
- The compiler keeps track of this bank ID, and if it calls a function in another segment (known by the bank ID), it calls a user defined "banking" function that sits in LOWCODE (or wherever.)  That function needs to be passed the bank ID (could be in the A reg), the destination function address, and it needs to have the originating bank ID pushed on the stack (either by the compiler or passed in so we can do it.) 
- if the function is in the same segment, just do everything like normal.

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

The Atari has a few different ways of banking in more memory: cartridge, and expanded memory being the most popular.   I imagine the user defined banking routine would like something like this for an Atari cartridge:

tax		(bank ID-defined in linker config to match the cartridge hardware I'm targeting)
sta $d500,x	(switch the cartridge bank)
call the function (get this from X+Y regs maybe, or from hardware stack)
pla		(pop the originating bank off the stack)
tax
sta $D500,x	(get back to the proper bank)
rts		

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.



-----Original Message-----
From: owner-cc65@musoftware.de [mailto:owner-cc65@musoftware.de] On Behalf Of Ullrich von Bassewitz
Sent: Wednesday, January 14, 2015 5:24 AM

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


----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Thu Jan 15 04:31:49 2015

This archive was generated by hypermail 2.1.8 : 2015-01-15 04:31:51 CET