Re: [cc65] Re: Porting to CC65

On Sun, Oct 10, 2010 at 8:29 PM, Ullrich von Bassewitz <uz@musoftware.de> 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.

Sorry, I should have made it clear that I'm treating "state" as a
single-byte variable (hence the LSB operator for the state constants.)
Mostly I need to avoid page-crossings in jump tables like these, data
indexed through self-modifying code and in timing-sensitive cases
where I can't afford cycle penalties.

> 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.

That sounds like a reasonable approach to me. Then I can even reorder
the tables to minimize alignment losses.

> 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.

I'll be careful with segment alignment then ;)

> 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.

Right, that's the version I eventually got working by making the macro
tail-recursive. Before that I tried recursing from within an if-branch
and hit a sixteen level nesting limit. I didn't mean to submit a bug
report or anything, I just wanted your take on whether I was abusing
the assembler in a way likely to get me into trouble.

>> 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.

I wouldn't be averse to implementing this feature myself and
submitting a patch, especially as the code looks surprisingly clean
and readable to me. How would you prefer to see it handled?

>> 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:-)

I suppose you're right, and at least I don't have to worry about
expressions with side-effects.
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.