From: Tim Vanderhoek (vanderh_at_ecf.utoronto.ca)
Date: 2000-02-20 00:49:00
On Sat, Feb 19, 2000 at 02:11:25PM +0100, Ullrich von Bassewitz wrote: > > * Is there a need to specify which one goes into the memory area first, LOAD > or RUN? Currently LOAD goes first, then RUN. Specifying an additional Hm. I can't think of any reasons to need a different order. An additional level of abstraction in the Config file would probably handle most of the wierd cases fairly cleanly, but ... I'm not sure if it's necessary. > * Currently the RUN range is never written to the output file, it is not even > written using fill bytes when FILL is set. This is usually ok with the old I think that if the linker's output is a binary file (ie. basically just a verbatim memory image) then all segments should be filled (possible exception: the last bss segment). > With the new feature this may lead to "holes" in the output file, Holes are very bad. :) There are arguments for filling the RUN area both with FILLVAL and with the RUN data. I think I would fill it with FILLVAL. POLA. > * Similar: BSS segments are never written to the output file. Is this needed > to make use of the duplicate LOAD and RUN area feature? Assume this: Actually, I'd run across this before and modified the linker to output the BSS segment. Then I realized there was no real need (save aesthetics) for the segment in question to be type=BSS. :) This may be a general truth: someone who needs to put BSS at the beginning of memory could probably just as easily get away with saying "type = rw". I don't think it's necessary to write-out type=bss segments. There's not much that makes a bss segment to be a bss segment, otherwise. :) > I don't know if this is a realistic setup for > the BSS segment, but people seem to do all sort of things I have never And it would probably break malloc(). :) -- Signature withheld by request of author. ---------------------------------------------------------------------- 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 : 2001-12-14 22:05:35 CET