From: Groepaz (groepaz_at_gmx.net)
Date: 2003-10-11 16:42:30
On Saturday 11 October 2003 13:45, Ullrich von Bassewitz wrote: > On Fri, Oct 10, 2003 at 06:37:14PM +0200, Groepaz wrote: > > i think whats needed is "scatter loading" support in the linker (and > > other parts of the toolchain that deal with accessing binary files) > > What do you mean with "scatter loading"? Loading an application in more > than one chunk? yes and no :o) "loading application in more than one chunk" is just one of the things "scatter loading" could be used for :o) [note: i am using the term "scatterloading" as ARM uses it in their docs, for the lack of a better wording/description] so with "scatter-loading support" i mean linker support for the following: >ability to construct "random" layouted binary files< which would maybe mean another stage in the linking process (or even an additional tool, but this would mean duplicating a lot of work already done in the linker). this feature should allow to configure the linker to do produce any of the following: - binaries with "holes" in them (like the atari machines can use for eg) - "scrambled" binaries of any sort (for example, split the binary into 254-bytes chunks and interleave them in a way that they can be put on raw sectors of a 1541 disc and then can be read back extra-fast) [this would allow to create "iffl" type of files with cc65 on the fly - very useful imho :=P] - "scattered" binaries of any sort (aka "spreaded code"), for example to create programs which need to use several small chunks of memory at a fixed location for data, and use the remaining space for code. (all kinds of FPP effects on the c64 are the prime example here, but i am sure there are other uses aswell, like programs using the videobank at $4000 or so) - "chunky" binaries of any sort. for example all .o65 support would be in a config file aswell. (geos vlir files fall into this cathegory, aswell as some emulator image formats others) and ofcourse, any combination of the above. i know this means adding several not yet supported features in the linker (like solving expressions, sorting symbols into blocks/sections of memory, creating tables for relocation or cross reference. > If so, I don't think support for this should go into the > linker, because it's highly platform dependent. Instead, a special startup > file could be used, together with (minimal) linker support. the startup file isnt really the point here (although admitted, it might need some customization for certain setups anyway)... and well, i'm fine with "minimal" linker support - anything platform dependend should go into the linker config file ofcourse :o) gpz ps: regardless of the above.... it would be cool if the linker could filter any input/output files through an external tool (which could be configured per file in the linker config) ... that way one could easily add some of the above mentioned functionality himself if other tools to do the job do exist already. ---------------------------------------------------------------------- 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-10-11 16:47:46 CEST