|
Post by turboxray on Jan 27, 2020 15:08:57 GMT
So I was making some include macros. Mostly to give labels additional details like this:
;.................................................
IncludeBinary .macro
start_\@ = * \1: .incbin \2 end_\@ = *
\1.size = end_\@ - start_\@ \1.size.hi = (end_\@ - start_\@) >> 16
.endm For a line like this:
IncludeBinary FontData, "..\base_func\video\print\font.dat" I'll have access to the size simply by using FontData.size. For incbins, I can use sizeof() but I'm pretty sure I'm limited to a 16bit value, where as the macro gives the full size (although requires look at size.hi). Either way, I like the convenience of it being an attribute built into the label.
This works fine and all, but it doesn't work for include vs incbin:
;.................................................
IncludeData .macro
start_\@ = * \1: .include \2 end_\@ = *
\1.size = end_\@ - start_\@ \1.size.hi = (end_\@ - start_\@) >> 16
.endm
Here's the assembly listing:
248 ;///////////////////////////////////////////////////////////////////////////////// 249 ; 250 0002 .bank $02, "Subcode 1" 251 4000 .org $4000 252 253 254 IncludeBinary FontData, "..\base_func\video\print\font.dat" 4000 start_00027 = * 02:4000 FontData: .incbin "..\base_func\video\print\font.dat" 4C00 end_00027 = * 0C00 FontData.size = end_00027 - start_00027 0000 FontData.size.hi = (end_00027 - start_00027) >> 16 255 IncludeData FontPal, "..\base_func\video\print\font.pal.asm", font.pal.asm 4C00 start_00028 = *
#[2] ..\base_func\video\print\font.pal.asm
FontPal: .include "..\base_func\video\print\font.pal.asm" 4C00 end_00028 = * 0000 FontPal.size = end_00028 - start_00028 0000 FontPal.size.hi = (end_00028 - start_00028) >> 16 1 2 3 02:4C00 .start 4 5 02:4C00 00 00 33 .db $00,$00,$33,$01,$ff,$01,$ff,$01,$ff,$01,$ff,$01,$ff,$01,$f6,$01 02:4C03 01 FF 01 02:4C06 FF 01 FF 02:4C09 01 FF 01 02:4C0C FF 01 F6 02:4C0F 01 6 7 02:4C10 .end 8 9 0010 font.pal.asm.size = .end - .start 10 11 #[1] main.asm 256 257 02:4C10 test1: #[2] ..\base_func\video\print\font.pal.asm 258 include "..\base_func\video\print\font.pal.asm" 1 2 3 02:4C10 .start 4 5 02:4C10 00 00 33 .db $00,$00,$33,$01,$ff,$01,$ff,$01,$ff,$01,$ff,$01,$ff,$01,$f6,$01 02:4C13 01 FF 01 02:4C16 FF 01 FF 02:4C19 01 FF 01 02:4C1C FF 01 F6 02:4C1F 01 6 7 02:4C20 .end 8 9 0010 font.pal.asm.size = .end - .start 10 11 #[1] main.asm
As you can see, the macro correctly builds the include. But the size never gets calculated (it's always 0) because unlike incbin, the macro doesn't expand the include inside the expanded code in the listing.. but rather afterwards! Not only is the size not calculable, but any contents in the include file is not accessible inside the macro (such as .start, .end, or font.pal.asm.size). As an experiment, I manually included the file right after the macro and everything is fine.
It's a bug in PCEAS (it's in the new version as well).
|
|
|
Post by elmer on Jan 27, 2020 21:56:47 GMT
I'll have access to the size simply by using FontData.size. For incbins, I can use sizeof() but I'm pretty sure I'm limited to a 16bit value, where as the macro gives the full size (although requires look at size.hi). Either way, I like the convenience of it being an attribute built into the label. PCEAS's sizeof(), and the rest of the internal PCEAS math, is done using an "int", so that's a signed 32-bit value on all of the modern platforms that I can think of. You can see that here ... #[1] testinc.s 2 3 00:E000 my_bin: incbin "teos-backup-2019-05-02.zip" 4 5 0F:F0DC DC F0 dw 65535 & sizeof(my_bin) 6 0F:F0DE 01 db sizeof(my_bin) >> 16 7 8 0F:F0DF 00 00 33 my_inc: db $00,$00,$33,$01,$ff,$01,$ff,$01,$ff,$01,$ff,$01,$ff,$01,$f6,$01 0F:F0E2 01 FF 01 0F:F0E5 FF 01 FF 0F:F0E8 01 FF 01 0F:F0EB FF 01 F6 0F:F0EE 01 9 0F:F0EF 00 00 33 db $00,$00,$33,$01,$ff,$01,$ff,$01,$ff,$01,$ff,$01,$ff,$01,$f6,$01 0F:F0F2 01 FF 01 0F:F0F5 FF 01 FF 0F:F0F8 01 FF 01 0F:F0FB FF 01 F6 0F:F0FE 01 10 #[2] ptest.asm 11 include "ptest.asm" 1 0F:F0FF 00 00 33 db $00,$00,$33,$01,$ff,$01,$ff,$01,$ff,$01,$ff,$01,$ff,$01,$f6,$01 0F:F102 01 FF 01 0F:F105 FF 01 FF 0F:F108 01 FF 01 0F:F10B FF 01 F6 0F:F10E 01 #[1] testinc.s 12 13 0F:F10F 30 00 dw 65535 & (* - my_inc) 14 0F:F111 00 db (* - my_inc) >> 16 15 16 0F:F112 20 00 dw sizeof(my_inc) 17 0F:F114 00 db sizeof(my_inc) >> 16 18 19
Where "teos-backup-2019-05-02.zip" is $1F0DC bytes long. This works fine and all, but it doesn't work for include vs incbin: Here's the assembly listing: As you can see, the macro correctly builds the include. But the size never gets calculated (it's always 0) because unlike incbin, the macro doesn't expand the include inside the expanded code in the listing.. but rather afterwards! Not only is the size not calculable, but any contents in the include file is not accessible inside the macro (such as .start, .end, or font.pal.asm.size). As an experiment, I manually included the file right after the macro and everything is fine. If you look at the "my_inc" above, you'll see that the include seems to start a new translation-unit, and that the my_inc label stops accumulating the count of .db bytes when the include is hit ... which seems like sane behavior, because unlike incbin/incspr/incchr/inctile/etc, the file that is included could contain bank switches and org changes and absolutely anything. It's a bug in PCEAS (it's in the new version as well). Whether it is actually a bug of not may be an eye-of-the-beholder sort of thing. It seems like what you're seeing is wrapped up in the internal implmentation of macros and how they interact with includes, potentially wrapped up with pass-1 vs pass-2 processing of labels ... i.e. it seems like a very grey-area of behavior, and something where any changes could easily have unintended effects.
|
|
|
Post by turboxray on Jan 27, 2020 22:57:32 GMT
Which is fine. And your "dw 65535 & (* - my_inc)" calculates correctly. What I'm saying, is that behavior should be the same inside a macro as well (everything that you described) - but it isn't. The expansion of the macro should be no different than the code itself as you presented it.
|
|
|
Post by elmer on Jan 28, 2020 7:45:35 GMT
Here's the assembly listing: 255 IncludeData FontPal, "..\base_func\video\print\font.pal.asm", font.pal.asm 4C00 start_00028 = *
#[2] ..\base_func\video\print\font.pal.asm
FontPal: .include "..\base_func\video\print\font.pal.asm" 4C00 end_00028 = * 0000 FontPal.size = end_00028 - start_00028 0000 FontPal.size.hi = (end_00028 - start_00028) >> 16 1 2 3 02:4C00 .start 4 5 02:4C00 00 00 33 .db $00,$00,$33,$01,$ff,$01,$ff,$01,$ff,$01,$ff,$01,$ff,$01,$f6,$01 02:4C03 01 FF 01 02:4C06 FF 01 FF 02:4C09 01 FF 01 02:4C0C FF 01 F6 02:4C0F 01 6 7 02:4C10 .end 8 9 0010 font.pal.asm.size = .end - .start
As you can see, the macro correctly builds the include. But the size never gets calculated (it's always 0) because unlike incbin, the macro doesn't expand the include inside the expanded code in the listing.. but rather afterwards! A quick look at the code confirms the behavior above ... a macro is a short override, reading the stored macro's text instead of the normal text input system, wheras an include changes the text input system to read new lines of text from a different file. This is different to incbin/incchr/intile/etc, which bypass the text input system entirely and just read in binary data directly from a file. That explains why the start_00028 and end_00028 values are the same when doing the include inside a macro. Sorry, but the system appears to be working as designed, and it seems (IMHO) to be working correctly. If I were to make any change at all, it would be to throw up an error, and say that it was illegal to put an include inside a macro. If the way that this all works is annoying enough to someone that they choose to rewrite the entire text processing for PCEAS in order to make it behave differently ... then I hope that they will send me a pull-request so that I can integrate the changes.
|
|
|
Post by turboxray on Jan 28, 2020 21:48:08 GMT
If I wasn't already working on a collab project, I totally would! I'd separate the tokenizer out as a first pass, and build a syntax tree to handle any level passes over the tree. But I do plan on adding a few arg types to the macros though. It's actually pretty great as-is right now, but I wanted a little more configuration on the types for nice might high level ISA macros. I'll post some ideas here and get some feedback when I'm ready
|
|