sjasmplus
sjasmplus copied to clipboard
N-pass assembling
Make it N-pass...
- [ ] refactor the global state into nesting assembling context, to resolve includes/nesting/substitution and have the state-preserving for free in natural C++ way, without explicit code
- [ ] categorize the state items per their life-cycle in 3-pass and N-pass, group it
- [ ] modify pass3 things to wait for "final pass" instead
- [ ] create checks to detect "pre-final" pass did happen
- [ ] just enable N-pass as last step :)
It should look like repeating pass 3 when all binary data is on their places
...or not
thinking about it now, it's more like repeating pass 2 until it does match pass 1 (failed pass 2 becomes "pass 1" for next iteration).
pass 3 is final pass, which should always match pass 2 perfectly (difference is reported as warning/bug), because during pass 3 the machine code is emitted and output files are written, so repeating pass3 would cause lot of file overwrite and would be lot slower than repeating pass 2. But pass2 whole purpose is exactly this, so...
Looking at my original checkbox plan, it actually looks more like refactoring of internals, the current code base is probably much more ready for N-pass than I think, just needs somebody brave enough to cover it with tests and try to do it. :)
BTW, this will cause most of the current projects to end doing 4-pass instead of current 3-pass, as only very small projects match pass1 and 2. But I guess if large code base takes now ~2.5s to compile, it will be like 3.0s, so not completely horrible.
also what about saving full labels variables lua variables arrays etc in file for load it in new "pass1\2\3" asm files?
agrhgh!!!! it will no macro in it (but it's not so bad)
during pass 3 the machine code is emitted
its need to read generated code to generate new code
this will cause most of the current projects to end
old 3 pass mode must be by default
it will be possible to direct call code unpacked from pack 1 from code unpacked from pack n
also i doing it now but now its difficult
its need to read generated code to generate new code
That's not how it is supposed to work. If you need this, you should build it in steps, producing binary files in stages, and have next asm file read that binary and generate new code based on that.
The "read emitted code in last pass" is just very limited hack, works good enough for something like XOR-checksum of data block or other post-process, but the code-block sizes (label values) should be final already from pass 2, if you are changing labels in pass 3, you are "misusing" sjasmplus design, and then it's up to you to misuse it the way as you need it, but I can't "fix" anything about it, as you are already outside the designed way.
old 3 pass mode must be by default
not really, the source will be unable to tell difference any way, unless it counts passes on its own... (the __PASS__
will return "2" for each re-run).