6502.org

The way I solved this was to do pattern matching before evaluation. The pattern is formed by leaving any top level parenthesis in place and marking anything that is a lower level parenthesis or part of an expression with a *. For example:

LDA foo,Y => LDA *,Y
LDA foo+bar,Y => LDA *,Y
LDA (foo+bar)+baz,Y => LDA (*)*,Y
LDA (foo+bar),Y => LDA (*),Y
LDA (foo+(bar+(baz))),Y => LDA (*),Y

Since the last two match the "(*),Y" pattern, I know they are indirect addressing. Since the others don't match any of the patterns I'm looking for, it's safe to assume they are not indirect even though they have parenthesis. This solves the problem with JMP direct/indirect and doesn't require { and }.

In my assembler I check for parantheses that are part of the addressing mode before attempting to evalulate the expression. You can use unary plus to force the parentheses to be part of the expression like this:

Personally, I've never understood the need to redesign assembler syntaxes. Every programmer seems to feel the need to design a novel syntax, instead of learning the previous. So there is a different assembly syntax for everyone who's written an assembler.

Personally, instead of writing yet another novel one, I'd suggest focusing on making your assembler accept as many existing formats as you can. Interoperability is a huge barrier to adoption.

To go even more against the flow and the probable consensus here, I prefer the assembler syntax introduced by Bill Ragsdale, with enhancements, even for stand alone assembly language programs.
That said, I would agree with drogon. It's your assembler, use a syntax you're most comfortable with. I wouldn't be too concerned with supporting the syntax of other assemblers, or adoption of your assembler, just yet. I recommend honing your assembler, make it most useful for you.
I would definitely read Garth Wilson's list of requests for assembler writers but balance that with what YOU want from your assembler.
You can always add support for the syntax of other assemblers as time and inclination allow.

I have to agree with you. I too fail to understand the compulsion to mess around with language syntax and create yet another assembler that no one will use because of source code incompatibility. Just imagine if other languages were like this. Imagine what C or FORTRAN or COBOL would have been like if everyone who wrote a compiler decided to come up with a new language syntax.

What is wrong with sticking to the MOS Technology 6502 assembly language standard under which countless millions of lines of code were written? As someone once noted, "Standards are so important everyone must have one." That's what is being promoted when yet another assembler with a strange syntax comes into being.

I understand your other examples, but I don't get this one.
Which addressing mode do you mean there?

(Sometimes one of us will find a project holds no great interest, or find we can't agree with the motivation or with the destination: in such cases it's best not to comment. It will be a matter of taste, and the conversation flows better if it's left to those people who do find it interesting. If that turns out to be no-one, so be it - but that's rarely the case.)

Hmm... Not sure whether you were referring to my post just above? While I am indeed not planning to write an assembler anytime soon, I am genuinely interested in the syntax question I asked, and was wondering whether there maybe is an undocumented addressing mode for the 6502. If it's a stupid question, could someone help me out anyway please?

No, your query was not one of the remarks which prompted my comment. Sorry for the ambiguity.

Then let me restate as some questions.

Who are you writing this assembler for? Yourself, or for others?

If for others, then which others?

If for yourself, are you writing it for fun or for a specific use?

I think the landscape of 6502 assembler syntax is quite varied - maybe no more so than, say, the landscape of z80 assemblers, but I don't know much about that. I think my preference is for the approach taken by ca65, the assembler in the cc65 package, which allows various options, for example about how labels should be done. But even so, I don't suppose anyone would try to construct a universal assembler, with all possible variations supported - so it's bound to be the case that someone's preference won't be satisfied.

However, it seems like a good idea to canvas which ideas are out there, and see how they appeal to one's own sensibilities. It's not possible to judge popularity from a straw poll, and you will get some idea of strength of feeling, but of course that doesn't always coincide with one's own judgement.

There is no addressing mode like that, so the assembler knows that this will be a direct instead of an indirect mode since it doesn't match "(*),Y". Any arbitrary pattern that doesn't match the ones the assembler knows is assumed to be a direct address. It's safe to assume that "LDA (*)*(*)*(*)*(*),Y" for example is direct addressing since it also doesn't match any patterns.
I really disagree with you there. If I had started this thread, it would be a disservice to let me spend months of time on a project without letting me know the downside of inventing my own syntax. It's not obvious at the outset that it's probably a bad idea. I think it's helpful to warn people of the pitfalls. They'll either appreciate the heads up or take it in stride and go ahead with their project anyway, which is fine if they understand what they're getting into. Holding back negative but potentially useful criticism for someone asking for opinions is not helpful.

One of the features I use and value most in the macroassembler AS is named local labels. Any label that starts with a period is considered local to the scope between the two nearest global labels. I find things like JMP .loop and BEQ .exit to be a lot more readable and reliable than using the equivalant + and - local label syntax.

I find this to be orthogonal to larger-scale .proc scoping, which is also quite useful in larger programs.
Actually, that's not an issue where the label must start in column 1 because you can just anchor your search to the beginning of the line. The point about indentation is a reasonable one, though.

As for the whole brouhaha about whether one should ever consider a new assembler syntax, while it's reasonable to point out the downsides of a new syntax, starting out your comment with "I don't understand why someone would..." is saying essentially "I am ignorant as to why someone would...." To me, unless that's preceeding a request for explanation to dispel that ignorance, that comes across as the poster being either unintelligent or too lazy to think about why someone would want to do this. Consider what your reaction would be to, "I don't understand why in this day and age someone would design a new system based around a 6502 processor."

I like that one. For my assembler, I'm toying with the idea of introducing nested scopes, with C-style { } or Pascal-ish .begin and .end. Symbols defined inside a scope are only visible within that scope. But I haven't implemented it yet, and have no experience with how usable (or unusable) it will be. If it doesn't work out, your suggestion is my next best choice. It won't allow nesting, but it's more readable than anything else I've seen.
I might use : instead of . though. Words starting with . are always directives to me.