Re: [cc65-devel] HuC6280 zero-page addressing problem.
cc65 - a freeware C compiler for 6502 based systems
Brought to you by:
gpz
|
From: John B. <jo...@te...> - 2016-07-07 17:03:00
|
> 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. |