You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was super happy to see your project since I've been looking for a mindustry assembly compiler and was scared I would have to write a compiler backend from scratch. This being said, there have been additions to the instruction set and I was willing to update code to include these instructions, but looking at the way compiler.py is implemented there seems to be a lot of finickiness I would have to overcome. For example, the @Unit constant and sensor instruction. With the current implementation, the '@' character is unable to be externed in c code, thus using Edit: that part is easy
Another thing I see as problematic is the sheer number of instructions added since the start of the project. In my view, parsing include/builtins.h for instruction declaration dynamically may be better than statically defining them all in instructions.py. The methods for processing instruction arguments are also hardcoded (eg elif name == "radar"), but again with the amount of instructions added generalization may be a good idea.
Considering the scope of the project, I don't really expect you to put in weekends into it and I am willing to take the project under my wing if you no longer are interested. If however you are still interested, just point me in the direction you want to go and I'll do my best to contribute to the compiler.
The text was updated successfully, but these errors were encountered:
I was super happy to see your project since I've been looking for a mindustry assembly compiler and was scared I would have to write a compiler backend from scratch. This being said, there have been additions to the instruction set and I was willing to update code to include these instructions, but looking at the way compiler.py is implemented there seems to be a lot of finickiness I would have to overcome.
For example, the @Unit constant and sensor instruction. With the current implementation, the '@' character is unable to be externed in c code, thus usingEdit: that part is easyAnother thing I see as problematic is the sheer number of instructions added since the start of the project. In my view, parsing include/builtins.h for instruction declaration dynamically may be better than statically defining them all in instructions.py. The methods for processing instruction arguments are also hardcoded (eg
elif name == "radar"
), but again with the amount of instructions added generalization may be a good idea.Considering the scope of the project, I don't really expect you to put in weekends into it and I am willing to take the project under my wing if you no longer are interested. If however you are still interested, just point me in the direction you want to go and I'll do my best to contribute to the compiler.
The text was updated successfully, but these errors were encountered: