In both RGBASM and RGBLINK, the struct Section stores a collection of struct Patches, which represent bytes that get patched over with values computed at link time from RPN expressions.
When #488 implemented assertions, it reused code from the patch mechanism to store RPN expressions which were being asserted to be true (nonzero). This had two consequences I'd like to fix.
One is that the Offset field of a patch is unused by the assertion (documented in rgbds(5) as an "unused leftover from the patch structure"), so it just bloats the object files a little bit.
The other is that the Type field of a patch ends up having two different meanings. For section patches it can be 0, 1, 2, or 3, indicating the type of patch (byte, word, long, or jr). For assertion patches it can be 0, 1, or 2, indicating the type of assertion (warning, error, or fatal). This results in some suspicious-looking code casting to/from contradictory enum values.
I'd rather just have separate code to write→read sections and assertions, without trying to reuse writePatch and readPatch functions for both. If we want to avoid duplicate code, there can be smaller reused units like "write/read RPNSize followed by RPNExpr". This would be a breaking change if we remove the unused Offset field from assertions in the object file.
In both RGBASM and RGBLINK, the
struct Sectionstores a collection ofstruct Patches, which represent bytes that get patched over with values computed at link time from RPN expressions.When #488 implemented assertions, it reused code from the patch mechanism to store RPN expressions which were being asserted to be true (nonzero). This had two consequences I'd like to fix.
One is that the
Offsetfield of a patch is unused by the assertion (documented inrgbds(5)as an "unused leftover from the patch structure"), so it just bloats the object files a little bit.The other is that the
Typefield of a patch ends up having two different meanings. For section patches it can be 0, 1, 2, or 3, indicating the type of patch (byte, word, long, orjr). For assertion patches it can be 0, 1, or 2, indicating the type of assertion (warning, error, or fatal). This results in some suspicious-looking code casting to/from contradictoryenumvalues.I'd rather just have separate code to write→read sections and assertions, without trying to reuse
writePatchandreadPatchfunctions for both. If we want to avoid duplicate code, there can be smaller reused units like "write/readRPNSizefollowed byRPNExpr". This would be a breaking change if we remove the unusedOffsetfield from assertions in the object file.