You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
People often think of labels as starting chunks of code/data of a particular size. Examples:
AddNTimes::; Add bc * a to hl.and aret z.loopadd hl, bcdec a jr nz, .loopret; SIZEOF(AddNTimes) is conceptually 7; SIZEOF(AddNTimes.loop) is arguably conceptually 4
wFoo:: ds3ds4 ; unusedwBar:: dw; SIZEOF(wFoo) is conceptually 3; SIZEOF(wBar) is conceptually 2
However, there's no way to get SIZEOF(Label) in rgbasm because it's not actually a well-defined concept.
A common heuristic for SIZEOF(GlobalLabel) is "how many bytes til the next global label", but that doesn't always work, as in the wFoo example above.
This isn't proposing any definite solutions yet, but exploring what such a solution could be, if any.
One use case for such a solution would be accurately reporting labels in emulators. You could see ld a, [wFourBytes + 3] instead of ld a, [$c103]. And it could lead to .sym output that's better able to be input for tools like mgbdis, which add :size metadata to symbols.
The text was updated successfully, but these errors were encountered:
Something that might work is, using the "distance til next label" heuristic as the default, but allowing the user to end it early.
An ENDSCOPE keyword, or ENDSCOPE <arg> for local labels, would return the current label scope to being nothing. (This is fine; you can continue declaring space/outputting data without a top-level label.)
For example:
AddNTimes::; Add bc * a to hl.and aret z.loopadd hl, bcdec a jr nz, .loop ENDSCOPE .loopretENDSCOPEnop ; unusedTheNextFunction:retassert SIZEOF(AddNTimes) == 7assert SIZEOF(AddNTimes.loop) == 4assert SIZEOF(TheNextFunction) == 1
I'd argue that there are too many possible interpretations, and that the default behaviour would have to be too complex, that this should not be integrated into RGBASM at all.
...You're right. I could imagine more keyword functionality to control a label's "size", but it would end up being less convenient than LabelEnd - Label.
People often think of labels as starting chunks of code/data of a particular size. Examples:
However, there's no way to get
SIZEOF(Label)
in rgbasm because it's not actually a well-defined concept.A common heuristic for
SIZEOF(GlobalLabel)
is "how many bytes til the next global label", but that doesn't always work, as in thewFoo
example above.This isn't proposing any definite solutions yet, but exploring what such a solution could be, if any.
One use case for such a solution would be accurately reporting labels in emulators. You could see
ld a, [wFourBytes + 3]
instead ofld a, [$c103]
. And it could lead to .sym output that's better able to be input for tools like mgbdis, which add:size
metadata to symbols.The text was updated successfully, but these errors were encountered: