Re: [cc65] The Contiki Desktop OS for cc65

Date view Thread view Subject view

From: Ullrich von Bassewitz (
Date: 2003-03-16 01:31:08

On Sun, Mar 16, 2003 at 01:12:12AM +0100, Adam Dunkels wrote:
> As Uz wrote in another mail in this thread, it isn't possible (or at
> least not advisable) to have dynamically linked functions in the module
> (i.e., the Contiki application program). So, instead we statically link
> all external functions and variables in the application program to the
> memory mappings of a well-defined Contiki version. For instance, lets
> say Contiki 1.1 gets loadable program support. In the C64 version of
> Contiki 1.1, the function ctk_widget_redraw() is put in memory 0x3ce1.
> Now, when we compile and link our Contiki application programs, all
> calls to ctk_widget_redraw() will be statically linked so that they will
> correspond to a call too 0x3ec1.

You can also do this for the runtime functions that are linked to Contiki.
What you need is some advanced perl magic that does the following:

  1. Extract the list of public functions from the map file (or debug info or
     whatever) together with their address.

  2. Create one big assembler file that just contains lines like

        .export booleq
        booleq  = $1257
        .export mulax
        mulax   = $2312

     and so on.

  3. Assemble this file and link it to your module *before* the standard
     library. This will cause the linker to use the symbols from this file,
     and only ressort to the code in the standard library if there is no such
     symbol exported from the Contiki main program.

Since the map file contains all public symbols, it would even be possible to
access variables from the module.

This way, modules would have almost zero overhead (just the code to load and
relocate the module).



Ullrich von Bassewitz                        
To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.

Date view Thread view Subject view

This archive was generated by hypermail 2.1.3 : 2003-03-16 01:31:18 CET