Glass Z80 assembler

Pagina 5/9
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9

Van Grauw

Ascended (8618)

afbeelding van Grauw

01-05-2016, 14:02

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?)

Van sjoerd

Hero (593)

afbeelding van sjoerd

01-05-2016, 15:14

I'd prefer 3, 1, 1.
a) Every Z80 assembly programmer will expect 'ld d,e' to be just that. Since option 2 makes it pretty much impossible to use those labels anyway, I think 3 is a better choice. An easy solution would be to just prefix all labels. Tongue
b) When someone writes and uses such a macro, he will expect ix to be replaced by iy. So 2 is the worst option. An easy solution would be to just prefix all macroparameters.
c) Z is just a flag, it can't be used as freely as registernames so I don't think there will be much confusion. if I'd thought about it, I would've made sure Sjasm would understand Smile

Van NYYRIKKI

Enlighted (5426)

afbeelding van NYYRIKKI

01-05-2016, 16:03

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

Van NYYRIKKI

Enlighted (5426)

afbeelding van NYYRIKKI

01-05-2016, 16:07

Grauw wrote:

@NYYRIKKI I think that’s what SECTION and DS VIRTUAL achieve, with a slightly different syntax.

The downside of DS VIRTUAL is that you have to add word "VIRTUAL" to every variable manually... Not a big thing though.

Van Grauw

Ascended (8618)

afbeelding van Grauw

01-05-2016, 16:28

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.

Van sjoerd

Hero (593)

afbeelding van sjoerd

01-05-2016, 22:14

Grauw wrote:

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

Well, in structs the label is not really 'c' but more like 'structlabel.c' so they're useable with all options.
But let's say option 5 could be to only give a error message when one would have to guess the meaning like 'ld a, c'. As long as the label is not used in places where a register could also be used, there is no problem.

Van Grauw

Ascended (8618)

afbeelding van Grauw

03-05-2016, 20:42

I added a few Hello World examples:

hellocom.asm
hellorom.asm
hellobin.asm

Van santiontanon

Paladin (863)

afbeelding van santiontanon

06-05-2016, 04:43

Thanks a lot for those examples Grauw! Specially the ROM one was very useful to me (I became curious about playing around with MSX assembler a few days ago Smile)

Van Grauw

Ascended (8618)

afbeelding van Grauw

07-05-2016, 00:26

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.

Van sfranck72

Rookie (23)

afbeelding van sfranck72

14-12-2016, 17:08

Hi Grauw,

2 questions please:
- Is there an implementation for a symbol file (If yes, what is the syntax) ?
- Can I produce a .txt file (like asmsx) to follow the bytes free with "print syntax" ?

Pagina 5/9
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9