On Fri, Oct 02, 2009 at 04:32:00PM +0200, Groepaz wrote: > i actually like the other approach better... in my current project (which is > an "OS" of some sort), i generate an "import library" from all symbols in the > kernel, which i then link against all applications (modules). this way > applications can loaded anywhere into memory, not only to a fixed place.... It has advantages and disadvantages: Relocatable overlays are larger, need longer to load, and the loader is ~0.5K in size. The advantages are that overlays can load anywhere and can be written more or less independently of the main application. All you need is the import library. As you can see from this list, your approach is actually better for things like an operating system, where applications are loosely coupled and may be written and managed independently from the main app (the OS). Olivers approach is better suited if the overlays are actually part of the main program and all you need overlays for is to gain more memory. > but ofcourse, each way has its uses :) Yes, exactly :-) > apropos, it would be very nice - and trivial to add - if the linker could > create such an import library :) (i'll write up a proposal with details when > i have some more time...) I'm not glad about having the linker output yet another file with information that is already contained in the existing files. How about a perl script that extracts this info from the map or debug file? The latter is probably easier to parse. I don't know if the debug file contains information about the "external" status of a symbol, but that can be easily added. 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.Received on Fri Oct 2 16:45:08 2009
This archive was generated by hypermail 2.1.8 : 2009-10-02 16:45:10 CEST