Re: [cc65] [ld65] Overwriting fillval for one segment only?

Hello,

* On Wed, Sep 05, 2012 at 01:52:56PM +0200 Ullrich von Bassewitz wrote:
> 
> On Mon, Sep 03, 2012 at 08:55:12PM +0200, Spiro Trikaliotis wrote:
> > Thus, what I would need is: Define the fillvalue for a memory area (this
> > already works), but if needed, overwrite it for one specific segment
> > with another fillval.
> >
> > Does this make sense?
> 
> Partially:-)

I see, you have more experience with this stuff. ,)

Ok, let's dig into it.

> What exactly is part of the segment?

The same rules apply as to memory area: Everything from the beginning of
the segment until the end of it, with:

1. The beginning is where the first defined byte of the segment is
   placed (that is, filler bytes before the first byte do not count),

and

2. the end is defined as the last byte before the next segment begins
   (according to rule #1).
   If there is no next segment, until the end.

   That is, filler btes at the end of the segment are part of that
   segment.


Sound reasonable to me, and it fits memory areas, at least as far as I
can tell.

So, specifically:

>   * Any fills that are caused by .res use the value from the segment.

Yes, part of that segment

>   * Any fills caused by .align at a given location within the source do also
>     use the fill value from the segment.

If the .align is inside of the segment, yes.

If the .align is for the first part of the segment, no.

>   * But how about alignment between the sections of a segment? Is this space
>     part of the segment or just part of the memory area?

Part of the segment.

>   * And how about alignment at the start of a segment caused by .align
>     statements in the source? Is this alignment part of the segment or not?

No, it is not (cf. above).

>   * Similar for fill bytes caused by the ALIGN, OFFSET or START attributes in
>     the linker config. Is the space part of the segment?

No, because these fill bytes are placed before the segment.


For me, it sounds reasonable. Any objections, not only from you, but
perhaps also from others?

Regards,
Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.