Re: [cc65] FAR handling?

Hi!

On Tue, Nov 01, 2005 at 12:31:05PM -0000, Keates, Mark wrote:
> What is the current state of 24 bit address handling in CC65?
> Is it just some thing that can be utilized at an assembler level?

Yes. And even at the assembler level, support is weak. That doesn't mean that
you can't write 24 bit code - of course you can. It means that there is no
automatic support by the assembler/compiler.

> I'm wondering how, in a 'C' source file, to declare an external
> function. Should there be a wrapper to indicate the segment?

As said above, there is no implementation. But the basic idea is: For a 24 bit
symbol, you don't need to specify a segment, because it's the address contains
all necessary information. Determining the segment when using near pointers in
a far memory model is more difficult. The compiler has to make some
assumptions that may be overriden by the programmer. Remember the

        char _cs* foo;

syntax in the borland compilers? There has to be something similar for cc65.

> Would the import (from the example below) be expected to look
> something like:
>
> 	.import		_far_func: far
>
> The docs begin to go into subjects like 'choosing the memory model'
> but this doesn't appear complete?

The 65816 is similar to the 8086 in this respect, and the plan was to add
support in a similar way: Symbols can be declared as "far" or "near". The
assembler will adjust jmp/jsr/rts accordingly. And the compiler will generate
matching code.

Please remember that 24 bit support is a long way to go: There must be support
for a 24 bit data type in the runtime library. Push, pop, inc, dec must be
implemented, and all helper routines that take 16 bit addresses must be
duplicated using 24 bit addresses. This alone is quite some work. Then, the
compiler must be extended to support 24 bit addresses, 16 bit addresses with
attributes, conversion between these types and so on. And finally, most of the
C runtime has to be rewritten for the 816.

> I think this would be a good area to push development against as
> many of the targets (e.g. Atari, Lynx, NES) are using bank switching
> models for cartridge development and this could aid us immensely.

There's a difference between real 24 bit support and banked memory. I don't
think that it is possible to implement full support in the compiler for the
latter, because platforms differ a lot in this respect, and it is quite
difficult for the compiler to figure out, what to do, if a function is banked
out.

But since the linker is rather smart and allows you to place more than one
block with code at the same address, you can write code for banked
environments today. Of course this is somewhat more complex than using linear
memory, but this is not the fault of the compiler. Just use wrappers for your
C functions that enable the memory bank, where the code lives, call the real
function, and on return switch back to the original bank. Such a wrapper could
look like this:

.proc   _foo

        lda     current_bank            ; Only if not __fastcall__
        pha                             ; Save old bank
        lda     #bank_that_contains_foo
        sta     current_bank            ; Switch to new bank
        jsr     real_foo
        pla                             ; Get old bank from stack ...
        sta     current_bank            ; ... and restore it
        rts                             ; Return to caller

.endproc

This works without problems since the call stack and the argument stack are
distinct, so the additional parameters on the call stack won't introduce any
problems when accessing the parameters in real_foo. The stack overhead can be
reduced by managing a separate stack for old banks.

Now, if you place all data segments, the segment containing the runtime and C
library, the segment containing main() and the segment containing the wrappers
in common memory, writing programs in a banked environment is possible.
Because of the overhead (stack and memory wise), you may want to keep banked
routines rather large and self contained.

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.