Re: [cc65] ca65 for stand-alone asm projects

From: Greg King <greg.king41verizon.net>
Date: 2010-11-11 11:47:13
From: "Ullrich von Bassewitz"; on Tues., Nov. 09, 2010; 04:45 PM -0500
>
> On Sun, Nov 07, 2010 at 10:37:53PM -0800, Agent Friday wrote:
> >
> > Also confusing about entries meant for only the benefit of binary
> > file creation is having to supply a START attribute.  It's really
> > superfluous to those sections, and it would be nice to leave it
> > out.
>
> What exactly do you mean with that? Each entry in the MEMORY section
> *must* have a start address and it *must* have a size attribute given.
> The address is used later to relocate the segments, when they're
> placed there; and, the size is used to check if not too much data is
> placed there.

Some headers/trailers don't have any addresses in them that need to be
relocated.  Therefore, any random start-address would work just as well
as any other address.  There are situations where a programmer wouldn't
care what the start address is; and, he wouldn't care about size-checks.
He doesn't want to be forced to name things that are totally irrelevant
to him.  There are values that are obvious defaults for those
attributes:  If "start=" isn't there, then it would default to zero.  If
"size=" isn't there, then it would default to the host compiler's
maximum unsigned int value.

>
> > Since the non-loading file sections have no place in the o65 format,
> > it seems you would need some such method to identify them.
>
> Not sure what you mean with that, either.

He's talking about the headers and trailers (they're read, but not
loaded into memory).

Agent, the answer to your question is "empty file-name attributes".  The
head and tail layouts would have this tag:
    file=""

Those layouts still would be built (symbol names would be defined); but
then, they would be thrown away!

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Thu Nov 11 12:53:33 2010

This archive was generated by hypermail 2.1.8 : 2010-11-11 12:53:36 CET