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

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

> From: Greg King <gregdk@us...> - 2016-07-06 05:54:07
>
> I think that it simply is the result of expression promotion.  ca65
> promotes them in the same way that C compilers do it.  When ca65 sees a
> line like this:
>
>        lda (regbank + 4),y
>
> it knows that "regbank" is 1 byte (because of .importzp).  Then, it uses
> GetConstAddrSize() to learn what is the width of the "4" (yes, its name
> is misleading; it should have been called "GetConstDataWidth").  Your
> previous patch said that the "4" is 2 bytes.  Therefore, the result of
> that addition must be promoted to 2 bytes -- which is illegal in that
> instruction.

Yes, that is why the previous patch was failing ... but AFAIK only on
instructions within "proc" scope because regbank is defined in global scope.

IMHO, it is a fundamental flaw with CA65's processing that a constant that
is used as an offset within an expression is being evaluated in isolation
in order to determine if the whole expression refers to a zero-page location
or not.

IMHO, the only reasonable way to determine that is to look at the final
result of the expression, and not its components.

If you look at StudyExpr(), you'll see that Ulrich apparently came to the
same conclusion, because there is override code in there to throw away
the result of that flawed process and to recalculate it based upon
the location of symbols alone, or the final result of a constant
expression.

Unfortunately, that code isn't getting consistently used when in "proc"
scope, because symbols (including .importzp symbols) that are defined
in global scope are treated as untrustworthy.

I'm not even sure why all this calculation is being done all the time
inside StudyExpr() instead of being in EvalEA() where it would seem to
me to naturally belong.


> My conclusion is that they are the wrong functions for what you want to
> do (but, I haven't found the better places).

I'll be interested to hear if you can find a better place.

I'd suggest moving the decision into EvalEA(), but you'd need to make some
pretty major changes to the expression evaluation code when in proc scope
in order to have it actually use and trust the values of symbols that are
defined in global scope.

That seems to make a lot of sense to me ... but that's not how it is being
done now, and you guys may know of some reason why that decision was made.