Re: [cc65] Re: Porting to CC65

On Sun, Oct 10, 2010 at 04:18:28PM +0200, doynax wrote:
> Here's an example of a typical usage in the player state-machine:
>
> state := *+1
>     jmp (states)
>
>     single_page 5*2
> states:
> st_dead = <*
>     .word do_nothing
> st_walk = <*
>     .word do_walk
> st_jump = <*
>     .word do_jump
> st_crawl = <*
>     .word do_crawl
> st_climb = <*
>     .word do_climb

Are you sure this table must be within a single page? A can only see a
requirement for word alignment, caused by the 6502 bug in conjunction with the
indirect jmp.

> Granted it's not a critical operation, and for really large stuff like
> full-page tables I can set up a separate segment, but I've got dozens
> of these so a less wasteful approach than a direct .align would be
> nice. Of course ideally I would have liked to place the aligned block
> in a scope and avoid hard-coding a size, but the limitations of ACME
> forced this approach.

A simple approach would be to replace the macro contents by an .assert, which
just checks if the data is within a page. This won't do any alignment, but
notify you about a page cross when linking.

You can also combine this with single segments for each table and place them
into their own memory area. This allows you to move the tables around without
touching the code when the linker notifies you about a page cross.

For word aligned data as in the case above (I assume), I would place all these
tables into one segment and make the segment word aligned. So you're wasting
just one byte for the alignment of the segment and not one byte per table.

There may be more solutions depending on your needs, but if you do really need
page alignment, there is probably no solution that works perfect without
manual intervention.

> Looking at the code it seems to align relative to the start of the
> segment within the object file and exports a minimum alignment
> requirement, yet the linker script still needs an alignment attribute.
> Is the segment alignment forced on each fragment from every object
> file?

A memory area that contains aligned segments needs itself an alignment that is
at least as large as the largest alignment of the segments contained within.
The alignment is not forced on each fragment, just on the sections (= part of
a segment that comes from one object file). This could be improved but is the
current state.

> Here's an example of the sort of thing I mean. This macros is used to
> generate sector interleave tables for the drive-code by recursively
> ticking off bits in a bit-mask representing the track:

The macro looks like it should work with ca65. Can you show me one that
doesn't work? I have had cases where it is better to split up a macro into two
or three to make it clean and working.

> Oh, and I realize that you're swamped with feature requests but better
> error messages for macro expansions would be really nice.

I know that, but thanks anyway:-) If it were easy to do I would have added it
already. So I cannot promise anything.

> Also an alternative macro pseudo-op (say .xmac) with pre-evaluated
> parameters (or perhaps a per-argument operator) would be great as it's
> awfully easy to forget to parenthesize expressions. I suppose I should
> be used to this from all those years of writing C code but I still
> managed to get bitten in that interleave macro ;)

You can already emulate that by using a wrapper macro and/or local symbols for
evaluation. And once you are familiar with it, it is no longer a problem:-)

> That sounds like exactly what I am trying to do, the equivalent of C
> header files, except I tried to export functions within a scope. So I
> might for instance refer access all loader-related functions and
> constants through a loader:: namespace, and ended up with colliding
> scope definitions in the include file and the module code.
> Being able to define the labels outside of the scope they belong to
> would kind of solve this problem but I'd lose the convenience of
> leaving out the prefixes within module itself, so I'll probably go
> back to prefixing my labels with "ld_" instead. Frankly namespaces in
> C++ also always seemed to cause more problems than they solved.

The reason for scopes not being as consistent as one would expect them are
historical. ca65 was once a rewrite (with some additional features) of a DOS
based 6502/65816 assembler. Relocative code and exports/imports were there
from day one, but scopes were added later. If I had to do it again, I would
change this and a few other things. But even as it is, it is probably one of
the most capable assemblers out there. Unfortunately its feature richness
comes with the price of additional complexity. But especially for larger
projects I think it's well worth the effort.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.