From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2000-02-19 14:11:25
I have a first solution for putting LOAD and RUN both in one memory area.
However, the patch leads to several questions that I want to discuss:
* 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
order would need an extension for the config file syntax. One could
imagine even more weird things: Separating the two completely so that
there are additional segments between the two.
* 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
assumptions in place, since the RUN area was assumed to be initialized at
runtime. With the new feature this may lead to "holes" in the output file,
since there may be initialized segments after the one with the duplicate
LOAD and RUN areas.
What would be the correct behaviour for a segment with both LOAD and RUN
specified? Should the output space for the RUN area be filled if FILL is
given for the memory area? Would it be helpful to write the segment data
a second time into the RUN space?
* 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:
MEMORY {
RAM: start = $1000, size = $1000, file = %O;
}
SEGMENTS {
BSS: load = RAM, type = bss, define = yes;
CODE: load = RAM, run = RAM, type = ro, define = yes;
RODATA: load = RAM, type = ro;
DATA: load = RAM, run = RAM, type = rw, define = yes;
}
Since BSS is never written to the output file, the following segment has
the wrong starting address in the image. Same for CODE, since the RUN code
is never written to a file. 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
imagined, so someone may actually need it;-)
Suggestions, anyone?
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 : 2001-12-14 22:05:35 CET