Re: [cc65-devel] HuC6280 zero-page addressing problem.

[John B. <jo...@te...>]

On Sun, Jun 26, 2016 at 11:03 PM, John Brandwood <jo...@te...> wrote:
> Anyway, my new patch is simpler, cleaner, limited, and works, so I'll submit
> an Issue and a Pull Request on gihub.

Well, I was wrong, the patch doesn't always work.

It breaks when used inside "proc" sections because of the symbol scoping and
the way in which CA65 tries to figure out what effective-addressing mode to
use.

Looking at the code path for determining the effective address has also
answered my previous question ...

> It would be even cleaner if the AM65_ALL_ZP define had included all of the
> zero-page addressing modes like it claims to do.
>
> Does anyone have an idea why it doesn't?
>
> It looks like the define is only used once in the codebase, and that in the
> place where it is used, it almost certainly should be including the extra 3
> addressing modes that I had to add.
>
> Could it be a bug?

The answer, IMHO, is "yes" it really is a bug.

The section of EvalEA() code that uses AM65_ALL_ZP exists to provide a
safe fall-back for determining the size of an EA when it cannot otherwise
be figured out.

As such, AM65_ALL_ZP really does need to include the extra 3 defines in order
to work properly.


The problem for my patch is that the expression "symbol + constant" is looking
at the size of the constant to determine whether an EA is 1-byte or 2-bytes.

But, if the symbol is already defined, then it throws away the answer and
just looks at the information from the symbol itself (i.e. importzp symbols
imply that an EA should always use a ZP instruction if possible).

Now, the reason that my patch works in the top scope, but fails within "proc"
scope is because the code that attempts to guess the EA is following different
paths, and doing some very strange stuff, because the code is inconsistant in
whether it attempts to resolve symbols in the parent scope.

In one place it does, and in another place it doesn't, and if is does, then
it doesn't really believe the answer that it's got anyway.

Because the EA code doesn't really believe that it has found the symbol if
it is in parent scope, then the override code doesn't get invoked, and the
EA calculation makes the wrong guess if the high-bye of the constant is
not zero.

Is there someone here that really understands EvalEA() and how it interacts
with StudyExpr(), and why things got to be as complicated as they are now?

It looks to me like the rules should be pretty simple, and that things are a
bit broken in there right now, but perhaps I'm missing something important?


Best wishes,

John