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

UZ <uz@musoftware.de> wrote:
> On Sat, Nov 06, 2010 at 07:10:26PM -0300, Daniel Serpell wrote:
> > > If I'm getting this right then we could import the symbol _main from
> > > the "usual" (aka non-standalone-asm-program) linker configs :-)
> >
> > Currently, cc65 emits a ".forceimport __STARTUP__" directive in
> > its assembly output if there is a main function defined in the .c file,
> > to force the inclusion of the C startup at link time.
> >
> > This could be replaced by an import of __STARTUP__ from the
> > linker config, and the special case for main removed from cc65.
>
> A useful suggestion from AgentFriday is probably, to place the headers in
> their own memory area, just to make clear that they're not part of what is
> loaded to RAM.

I think that's a good complement to providing alternate targets for
simple asm projects (like c64-asm)
there's one suggestion that might round out the solution.

The MEMORY section of the config file is a bit of a misnomer.  While
the entries themselves are tailored for describing the addresses of
RAM areas, the overall function of the section is to specify what
goes into the "binary" file format.  I've never used the o65 format,
but perhaps the same is not true there.

Using a name like LAYOUT or FORMAT, rather than MEMORY, would better
represent its broader purpose.  LAYOUT is probably best, since it
can apply equally well to memory as well as files.

Also confusing about entries meant only for 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.  My suggestion would be to provide another TYPE attribute value
of "file" or "meta" to signify the non-load sections.  (These
entries are implicitly read-only, so to speak, and the TYPE doesn't
provide any useful information either.)  Another option might be to
specify something like "START=none", but this is less clear.

Since the non-loading file sections have no place in the o65 format,
it seems you would need some such method to identify them.
Otherwise, would the o65 generation code know to leave them out?
It would be nice if you could choose between the binary and o65 file
formats without having to make multiple changes in the config file--
maybe even w/ a command-line override param.  (In case you are
wondering, I do actually have a project in mind where I would want
to produce either format at will.)


// Agent Friday
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.