Druzyek wrote:
Do you think it happens often in practice that an 8 bit symbol becomes 16 bit but could be shrunk back to 8 bit after other symbols are resolved?
How about this?
Code:
ORG $FD
LDA $1FF-LABEL
LABEL
Pass 1: at LDA, LABEL isn't defined yet, so choose absolute addressing; at the definition of LABEL (on the next line), LABEL is $0100
Pass 2: absolute addressing was chosen in pass 1, but $1FF-LABEL is $00FF, so let's choose zero page addressing instead, and schedule pass 3; LABEL is $00FF
Pass 3: zero page addressing was chosen, but $1FF-LABEL is $0100 so absolute addressing must be chosen instead; LABEL is $00FF
Pass 4: same as Pass 2 and around and around we go unless we put a stop to this somehow
Obviously, that is not a piece code anyone is going to write. This looks pretty normal, though:
Code:
ORG $1000
LDX #0
LDA #$FF
.1 STA BUF+$1FF,X
INX
BNE .1
JMP START
DB "0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF" ; padding
DB "0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF"
DB "0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF"
DB "0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF012"
BUF
DS $300
That assembles without any trouble. Most of us don't usually type things in correctly the first time, though, and if I instead (mis)type ORG $000 and STA -BUF+$1FF,X then this is the same as the earlier situation.
Obviously, it's highly unlikely that you'd actually encounter such a situation (making those particular typos, BUF just happening to be on a page boundary, etc.), but if the planets ever do align, the thing to consider here is what the user will experience.
You certainly don't want the assembler to appear to hang (even in an extremely rare situation) merely because there are typos in the user's source code, so limiting the number of passes is wise.
With a traditional 2 pass assembler (use absolute addressing if a label isn't/wasn't yet defined in the first pass), the source code will assemble without errors, but the user (ultimately) will be able to find the typos after running the program and/or examining the list file output.
What is the user interested in? Getting the program working, and the first step is finding the typos. There are a couple of good approaches. If you can catch the problem at assemble time and point the user to a specific line or lines, great. If that's too hard, it will be helpful to the user to give not-what-the-user-expected assembly output, which the user can use to try to figure out why the unexpected result happened.