structs and label locality
abekermsx opened this issue · comments
There's a bug in how MDL handles instances of structs and label locality (at least when using dialect sjasmplus). The code below is transformed incorrectly:
STRUCT Data
Field: BYTE 0
ENDS
.data1: Data
.data2: Data
It is transformed into:
Data: equ 1
Data.Field: equ 0
Data.Field.data1:
Data.Field.data1.Field: db 0
Data.Field.data1.Field.data2:
Data.Field.data1.Field.data2.Field: db 0
The correct result would be:
Data: equ 1
Data.Field: equ 0
.data1:
.data1.Field: db 0
.data2:
.data2.Field: db 0
Are you talking about z00m's sjasmplus? Then your code sample is somewhat ambiguous and result is different:
# file opened: console_input
1 0000 STRUCT Data
2 0000 ~ Field: BYTE 0
3 0000 ENDS
4 0000
5 0000 00 .data1: Data
6 0001 00 .data2: Data
7 0002
# file closed: console_input
Value Label
------ - -----------------------------------------------------------
0x0001 X Data
0x0000 X Data.data1
0x0000 X Data.data1.Field
0x0001 X Data.data2
0x0001 X Data.data2.Field
0x0000 X Data.Field
Ambiguous, because local label without any global label should be prefixed with _., so if you just quickly look at your example, it looks like you define _.data1 symbol, but the struct name itself works as global label, which is somewhat unintentional and more like implementation quirk than a syntax rule.
So in the first place I would recommend to not use source like this, and define proper global label ahead of local label usage.
And mdlz80's Data.Field.data1 is actually what sjasmplus was producing just couple of versions back (it was fixed in v1.18.1)
And now I'm considering to fix even the leak of struct name as global label, but I don't know, can't people just not write source like this, and not depend on the quirk at all?
Yeah I'm using z00m128's sjamplus, it's working fine for me (ok, I didn't try this exact example).
I just posted an example that is as short as possible, when adding an extra label the code generated by MDL v2.3 is still not correct:
Data: equ 1
Data.Field: equ 0
label:
label.data1:
label.data1.Field: db 0
label.data1.Field.data2:
label.data1.Field.data2.Field: db 0
Oh, thanks for the report!! I'm making a note of this and will fix and add a test case to the code base!
Based on ped7g's comment I'll make sure to get the latest sjasmplus (post v1.18.1) to get a reference of the expected resulting label names.
I would consider the first example bad-practice and could break in future versions of sjasmplus (and I don't think it's very important what mdlz80 will produce in that case), but the second example is work for you Santion. :)
In sj that will produce:
# file opened: console_input
1 0000 STRUCT Data
2 0000 ~ Field: BYTE 0
3 0000 ENDS
4 0000 label:
5 0000 00 .data1: Data
6 0001 00 .data2: Data
7 0002
# file closed: console_input
Value Label
------ - -----------------------------------------------------------
0x0001 X Data
0x0000 X Data.Field
0x0000 X label
0x0000 X label.data1
0x0000 X label.data1.Field
0x0001 X label.data2
0x0001 X label.data2.Field
Ok, sorry for taking so long to look at this. But I just had the chance to take a look. There was a bug indeed! And the funny thing is that there was even a unit test that ensured the behavior was wrong hahaha.
I just fixed it, and added this as a unit test for safety. It's fixed in this pre-release: https://github.com/santiontanon/mdlz80optimizer/releases/tag/v2.4dev
I'll close this issue for now, but feel free to re-open if the fix doesn't fully fix it :)
Thanks a gain for the report!