From: Ullrich von Bassewitz (uz_at_musoftware.de)
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).
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2003-03-16 01:31:18 CET