Const Block Warm-up #7
Conversation
| ops = testProg(t, "intcblock 0x01 0x02; int 0x02", AssemblerMaxVersion) | ||
| expected = []byte{byte(AssemblerMaxVersion), 0x20, 0x02, 0x01, 0x02, 0x23} | ||
| require.Equal(t, expected, ops.Program) | ||
| // Previous int pseudo-ops should be pushints |
There was a problem hiding this comment.
We probably have a tough time really knowing what's "previous" here, right? In this example it's correct, but with branching, you could have some code that appears before other code, but runs later.
There was a problem hiding this comment.
I agree, but it's also pretty nonsensical to only have a single intcblock but then also not put it at the beginning (except for some potential dynamic cost saving I suppose). I'm happy to change it to just if you manually put in a const block, the pseudo-ops all go to pushint/pushbytes, but this means that people who want to manually set up const blocks now also have to manually index them.
Another option could be to require the const block setups to be the first ops or else the pseudo-ops just go to pushint/pushbytes
todo: add test cases for byte constant disassembly, handle terminating const blocks
Addresses the bytecblock portions of issue 4034 where the assembler has bad interactions with the byte pseudo-ops.
Remain to be addressed in later updates tonight: intcblock side of things, disassembler, and what to do if exactly one const block manually created but unclear whether block will be made before or after pseudo-ops