Re: [cc65] Loadable overlays

Hi,

> 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.

The script is here:

http://contiki.cvs.sourceforge.net/*checkout*/contiki/contiki-cc65/make-labels?revision=1.2

> Because the main code is rather big, it does contain most important
> runtime routines, and the latter case is rare.

You might want to consider these additional notes:

- Some parts of the cc65 C-Library make use of cc65
constructors/destructors. These are not called when the code in question is
linked to a loadable module - at least not without additional precautions.

- Some parts of the cc65 C-Library have an internal state (sometimes, but
not always initialized by a constructor). There are case where you might
want that state to live in the main binary rather than in the loadable
module(s), because of lifecycle considerations or because they are
singletons (which might be an issue if you load several modules
simultanously). Think in the direction of malloc()/free().

- Parts of the cc65 C-Library linked to the loadable modules use disk space
for every module. If you load several modules simultanously then not only
disk space but RAM.

For these reasons you might want to carefully check your map files to see
what parts of the cc65 C-Library are linked where. Check out the
.forceimport assembler directive for taking control over linkage of cc65
C-Library parts to the main binary like here:

http://contiki.cvs.sourceforge.net/*checkout*/contiki/contiki-apple2/lib/import.S?revision=1.2

Another more subtile issue might be that for the main binray the cc65 linker
config file gives you great flexibility on how to place the different
segments in memory. On the other hand the module loader in the cc65
C-Library just puts all module segments in one single heap block. Two
examples of more sophisticated segment handling are:

- Reusing the INIT segment after cc65 C-Library initialisation.
- Copying R/O segments into several memory banks to get "pseudo-bank-shared"
memory.

Best, Oliver

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.