Replies: 1 comment
-
The reason why we have this limitation is MASM is that I tried to keep MASM parser/assembler as simple as possible. I'm definitely open to relaxing this condition on the MASM side - though I wonder if it will actually be simpler as most likely a lot of the parser/assembler code would need to be refactored (or at least this is my immediate reaction - I could be wrong). |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
One problem we have to solve in the compiler is that high level languages more often than not allow functions to be referenced before they have been defined in a source file. In our case, the simple solution is to topographically sort the call graph during compilation, error on any cycles (which would obstruct a topographical sort), and then compile them to MASM bottom-up.
While we could do that in the compilation pipeline that lowers to MASM, it seems to me like that might be better done in MASM itself, as this would make MASM easier to write and read, since you would be able to put less important procedures near the bottom of a source file, and/or divide a file into public/private parts such that all of the public procedures are defined first, followed by all of the implementation details. Since MASM is the primary way users interact with the Miden VM at the moment, that might be a usability win and solve a problem we'll have to solve anyway.
In any case, this has to happen one way or the other, its just a matter of where we choose to implement it. I'm curious to hear everyone's thoughts on this though.
Beta Was this translation helpful? Give feedback.
All reactions