Glass Z80 assembler

Page 21/21
14 | 15 | 16 | 17 | 18 | 19 | 20 |

By inchl

Expert (65)

inchl's picture

13-08-2022, 23:47

Is there a way to declare a label top-level instead of being a child of the current proc? I tried naming with a @-prefix but that just became part of the name. Feature request :-)

Stephan

By inchl

Expert (65)

inchl's picture

21-08-2022, 12:23

I did not expect this result.

          ld hl,value    ; this line compiles as ld hl,(#0003)
value:    equ (1+2)

The unnecessary parentheses is due to the fact that its generated source code. I changed the source code generator so it will always prefix the value behind the equ with 0+

By Grauw

Ascended (10617)

Grauw's picture

21-08-2022, 14:14

Hey inchl, it’s been brought up before… Really it is unfortunate that in Z80 assembly syntax () has a double meaning, both expression grouping and instruction value indirection.

By Pokun

Resident (53)

Pokun's picture

21-08-2022, 15:39

Some assemblers has both types of equates, one (using "equ") for literal string substitution like C's #define and a separate one (using "=" for example) that evaluates the expression to a number first so that you can use whichever fits the situation best.

By Grauw

Ascended (10617)

Grauw's picture

21-08-2022, 17:16

Good to hear that other assemblers have similar struggles and how they solve it. Though I don’t think there is a need for a separate keyword, if you want to evaluate the expression to a number first the simple solution is as inchl did by prefixing with a + like equ +(1+2).

By inchl

Expert (65)

inchl's picture

22-08-2022, 12:00

I don't think its a good idea to let the equ definition determine how the opcode that uses it is compiled. In my opinion all equs should be treated as a numeric value. When the 'ld hl-opcode' uses () its should be an address, otherwise a number (or when explicitly overruled by a + prefix)

By Pokun

Resident (53)

Pokun's picture

22-08-2022, 17:51

I see benefits both the complete substitution type and the evaluated number type for different situations.
A macro instruction would work like the substitution in many cases though, it might depend on if macros are allowed to be put anywhere.

By santiontanon

Paragon (1652)

santiontanon's picture

23-08-2022, 11:31

I think that as long as the semantics of the operators is properly and consistently defined in the documentation, both options are fine. Perhaps the problem comes from the fact that different assemblers have different semantics for the "equ" keyword, some of them using string substitution, some using lazy expression evaluation and some using eager expression evaluation. So, porting code/expectations form one assembler to another is tricky...

Page 21/21
14 | 15 | 16 | 17 | 18 | 19 | 20 |