Hi, > [...] 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). Like for example Contiki 1.x which therefore uses this approach. > 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. Maybe some additional aspect: - If the chunks of code to be loaded by the program are so large that only one fits into memory at the same time than there's no real benefit in the whole relocation feature. - If parts of the C-library come from labels of the main module while others are actually linked into the loadable module (because they were not needed by the main module) then this can cause nasty effects inside the C-library. - If parts of the C-library get linked into the loadable modules that contain constructors/destructors those won't be called. From my experience you have to have very intimate knowledge of the C-library (ideally you've written it) so you can add the "right" strategic '-u' options when linking the main module in order have the problematic C-library parts for sure linked into it. So after all from my perspective this approach is indeed very cool - but it's still a fragile hack. The "single link to multiple output files" approach on the other hand is way more simple and stable compared to that. Therefore it should be propagated to the non-insider cc65 user. Surely the user must manually adjust the amount of code he puts into the overlays to the memory area size. But looking at map files and manual adjusting code placement is typically necessary for overlay linking anyway to make the several overlays match in size. Best, Oliver ---------------------------------------------------------------------- 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, 2 Oct 2009 21:54:33 +0200
This archive was generated by hypermail 2.1.8 : 2009-10-02 21:54:44 CEST