In defence of ca65 (mostly because it's what I use right now), it's really part of a "classic" Unix style compiler/assembler/linker suite rather than a stand alone assembler like a "normal" 8-bit implementation might be, so it's really intended to assemble separate modules then link them together to produce the final object file.

You can get fully qualified output when you switch relocation off - ie. use a .org in your code - then you'll be simply including source files, if you have a project in separate files.

Some ca65 list output from my first stage bootstrap loader in Ruby:



Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

How about this?

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:

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.

The case where you have code on the border with zero page does seem pretty rare. I was thinking more about where a label is the input into an assembler function or macro which outputs code or data and the size of that depends on the label. If the label comes after the function, you could get an endless loop like you describe above. This might be a little harder to imagine but when any arbitrary calculation is allowed on a label in a macro, the problem seems a lot more likely than code on the edge of zero page.

Bah - I added high and low modifiers to my expression evaluator and killed the damn thing. Now it can't do +-*/ which is a pain. Oh well, shouldn't be too much trouble to sort... I didn't notice it at the time as my stress test didn't have any expressions in it

As an aside, is there a generic N6502 and/or WDC65C02 stress test available anywhere? The obvious candidates are the microsoft basic and figforth listings, but they're both N6502 only, I think.

Neil

I'm not aware of a stress test specifically for assemblers. There are several for the instructions, of course. One difficulty would be the wide variety of syntaxes in use, and of the different features supported. For a fully comprehensive test, you'd really need a different one for each assembler. Or write a program that can parametrically generate a test targeting your particular assembler.

I've been using Microsoft BASIC and C64 KERNAL for mine, after some semi-automated massaging to get it into a format that my assembler will accept (the worst problem was their frequent use of leading 0 to mean 'octal', which I refuse to support). But that's far from perfect - this large complicated program, filling nearly a quarter of the 6502's addressable memory, never uses the (zp,X) addressing mode. Guess which addressing mode my assembler failed to parse correctly.

This question is almost a FAQ for assembler authors. The "correct" answer is non-trivial.

https://eli.thegreenplace.net/2013/01/03/assembler-relaxation

I added JEQ, JNE, JCC, etc. to my assembler a few years ago. They generate a relative branch if possible otherwise an opposite branch over a JMP. I was playing with a compiler for something and this simplified the code generation. The structured programming commands in my assembler also do this.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Yes, this technique is as old as the 6502 itself -- Bill Gates used it.

That said, all instruction sets (not just the 6502) are full of cases where the addressing mode should change, based on the relative offset or the size of the destination pointer. For example, the 6502 has tons of instructions of the form PPP QQQQ,X where the opcode for PPP changes based on whether QQQQ is an 8 bit or a 16 bit address. A good assembler/linker combination will be able to choose the correct form, but will also be able to deal with the cascading effects of changing the length of one instruction, thus requiring other nearby instructions to change addressing modes as well.