Glass Z80 assembler

Well,

Glass used to do: 2, 2, 1. The inconsistency was giving me some trouble to implement something, so now it does: 2, 2, 2, ignoring symbols for flags and registers entirely. However it would also be nice to not treat any identifier specially, and allow maximum freedom to redefine everything by going for options 1, 1, 1.

But maybe it’s better to treat the registers and flags as reserved keywords and not allow symbols with the same name to be defined, like options 3, 3, 3 (errors). To protect the programmer against unintended errors by forbidding him to write misleading code. Also this option allows me to choose either other option in the future without breaking backwards compatibility again, so I’d not be locking myself in to this decision.

However that would disallow (x, y, z) or (a, b, c) to be used as labels which seems not uncommon in data structures, and I also kinda like the second example where I can generate ix / iy versions of code with macros while keeping the code looking as normal. This also ties in to plans I have for adding a method signature to PROC. I also like the ability to redefine instructions so the user can add functionality to them, this should ideally be consistent with the flags and registers behaviour.

So yeah, I’m not entirely sure which would be the right decision, so some opinions of what as a programmer you would like would be good to help me make up my mind.

What appeals to you more; maximum flexibility and a generic scoping model which even applies to registers, flags and instructions? Or being prevented from shooting yourself in the foot by reserving some symbols as keywords, and just add some prefix or suffix to your labels when they conflict. Or something inbetween? (what?)

I would say: 1&4, 1&4, 1
With 4 I mean something like "Reserved word repurposed"-warning.

sjoerd, NYYRIKKI, thanks for your opinions, it’s helpful.

sjoerd: With a) option 2 you can still use the labels in structs, which is where I would usually have them.

NYYRIKKI: What I tend to do is have org 0C000H / RAM: DS VIRTUAL 1000H, and then generate all the RAM stuff there with SECTION RAM / ENDS (like your nosave), which phases the address pointer to be inside the RAM DS. Alternatively, you can have the RAM section non-virtual, and move it automatically from ROM to 0C000H at the program startup, which is pretty nice.

I added a few Hello World examples:

hellocom.asm
hellorom.asm
hellobin.asm

I made a change so that org only affects the address of the lines that follow it. This slightly breaks backwards compatibility if you labeled the org line like so: symbol: org nn. Previously symbol would get the value nn, now symbol will get the value of the address counter before the org, as if the label was on the line before it.

This allows to use $ in org directives meaningfully; previously, it would resolve to an uninitialised address. Also it’s more consistent, as labels and $ also always refer to the value of the address counter before instructions.

It will also allow me to make a parsing change in the future, to make labels associate with statements that follow them, not requiring them to be on the same line necessarily; the old org behaviour would then give unexpected results.