Re: [cc65] Loadable overlays

On Thu, Jul 27, 2006 at 02:47:21PM -0400, Payton Byrd wrote:
> 1) If the Kernel ROM is enabled, and there's 41K available to CC65, then
> bank is CC65 executing code in?

It's the first bank. The second bank is unused, because a bank switched
configuration needs special consideration.

> 2) Can C code compiled with cc65 reenable the MMU and change the current
> bank by setting the correct registers without blowing up the cc65 runtime
> when the bank is returned to 0?

The MMU is not disabled, it is just configured in a special way. There's no
problem switching banks. You can do that from C code, but if you switch away
any part of the program or its data, and then try to use the missing code or
data, your program will go nuts. This is true for any code that does bank
switching.

> 1) Is it possible to like the CC65 runtime library at the beginning of an
> executable so that the entry points to the methods and structs will never
> change?

What do you mean with "will never change"? For one compiled program, they will
not change anyway. If you change the main program and recompile, they may
change regardless of the location of the runtime library, because there is no
such thing as a "runtime library" - at least not if you think of it as a whole
block of subroutines. Instead, the runtime consists of several hundred
subroutines that are linked to your program if and only if your program needs
these routines. So if you change your program, you may need additional
subroutines, which are then added by the linker. As a result, the runtime part
of your program will change.

Assuming that you want to use the runtime from more than one loadable module:
This is what Contiki does using a clever idea and some perl magic.

> 2) Would it be possible to link a collection of o65 files to a specific
> upper memory location and then create a custom link configuration that would
> allow a program to be linked with a static map to those entry points?  Maybe
> this is the way to implement linking question 1...

Contiki takes the following approach: The main program is compiled and
generates a debug file containing the names and addresses of the runtime
functions. A perl script transforms this into a label file, where the name of
each runtime routine is assigned its address, and this address is exported.
This label file is compiled into an object file and linked to the loadable o65
modules before the runtime library. So if a loadable module references a
runtime library symbol, the linker will first check the label file, and if the
symbol is found there, it will replace the call by a call to the main Contiki
code. If the symbol is not found, the code from the runtime library is linked
in. Because the main code is rather big, it does contain most important
runtime routines, and the latter case is rare. The disadvantage of this
approach is that you must recompile all modules when you make changes to the
main code, because the location of the runtime functions may have changed.

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.