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 :-)
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+
Hey inchl, it’s been brought upbefore… Really it is unfortunate that in Z80 assembly syntax () has a double meaning, both expression grouping and instruction value indirection.
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.
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).
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)
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.
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...
