They need to be buildable the normal way (Kickass, Acme or whatever) so I can compare the output binaries...

@Krill: never mind, works now :)

One thing i just came across again:

It would be nice to have the assembler emit an actual 16-bit operand with things like "lda $0000" and "sta $0000,x" as opposed to "lda $00" etc.

They seem to consistently insist on knowing better and "optimise" the code for zeropage access.

To counter this, all kinds of syntax (one fuglier than the next) to force specific address sizes were invented. Ugh. =)

Tricky case. Do you have a suggestion for a good rule for this except in the trivial case with a constant?

I thought you didn't like it being explicitly annotated? Maybe I assumed wrong?

Yes, but what about things like:

      lda lab,x
lab   equ $f0 + 15

Do you want lda <abs>,x or lda <zp>,x?

Quoting tlr

Yes, but what about things like:

      lda lab,x
lab   equ $f0 + 15

Do you want lda <abs>,x or lda <zp>,x?

Sum is $ff, so this is not really ambiguous yet, i guess.

I'd implement the type promotion from ZP to mem16 access to happen when the result is at least $0100.

If this would be

lab = $00f0 + 15

instead, it would mean mem16 access, as the biggest type is mem16 in that expression.

$100 - 15 would be a better example. If the result is interpreted as zp, then the behaviour would be different.
Your idea with mem16 would solve that case if I understand it correctly.

I would skip the whole math and just use what's in the code, that is.

lda $f0 + $0A = lda $00 (still zp)
lda $00f0 + $0a = lda $0100

But since Sasq says it's more complicated to parse or whatever... well, too bad. I'm just saying what I'd be happy with

So what is the rule ? How do we know what the code actually means ?

How do we know what the code actually means ?

what about the parent scope, or an absolute reference, i.e from the global scope?

I couldn't find a good comparison on how this works in different languages.

As for means of access to a specific parent scope (without using it's name) I see little value in that. It's a good idea to name labels meant for cross-scope access unique while stacking up scopes. That way there's no confusion over which label or scope in which parent scope is referenced in a child.

"+" is for numerical sum only because calculations may be performed with strings. For example 1 - 'a' + 'z' is 26 (if letters are encoded in a sequence). Therefore concatenation must have a different operator.

I thought single quotes would denote chars (which allow arithmetics) and double quotes strings. This would neatly allow + for string concatenation, as it does in C++ and other languages.

Label of a block is always at its start. However it does not have to be used as an entry point. Usually for such special functions I write something like below:

					    *=$1000

.1000	20 06 10	jsr $1006	    jsr stuff

=$1006					stuff = (+).entry
.1003					+   .proc
.1003	9d 00 04	sta $0400,x	lp  sta $400,x
.1006					entry
.1006	e8		inx		    inx
.1007	d0 fa		bne $1003	    bne lp
.1009	60		rts		    rts
					   .pend

An anonymous symbol was used as it's only used in the expression above to get the entry point.

Named parent scope access is exactly what it sounds:

b1   .block
label1
b2a    .block
label2
       .bend
b2b    .block
c1       .block
         jsr b1.label1
         jmp b1.b2a.label2
         jmp b2a.label2
         .bend
       .bend
     .bend

After all labels of parent scopes are visible for children.

As for "parent" PC I usually just put a label in front:

						      *=$1000

.1000						label .logical $800
>1000	0800	00 10				      .word label
						      .here

Such a label is more useful for the installer code than the relocated one. As a .logical/.here block is just a relocation and so there's no label scoping.

But I see the point. If an assembler insists to scope every block then tough luck.