RFC: Updated/custom AS builds
Closed this issue · 7 comments
So, I have decided to fork this repository into this one. I managed to get AS building on Windows with msys2, and I am thinking of setting up some GitHub actions to make Windows/Linux/OSX builds.
So far, the latest branch required:
- one commit to get building;
- one commit to ignore build cruft;
- one commit to fix a stupid decision of making
message
useless by suppressing its output in quiet mode; - one commit to fix a segfault introduced probably in asl-current-142-bld193 when defining symbols from the command line.
I can probably also add some improvements and fixes while I am at it; one thing I was thinking of was a way to toggle the zero-offset optimization on or off. I did a quick test on S2 disassembly, and it would require being able to toggle it in code.
Any thoughts?
I would definitely enjoy a custom version of AS hand-tailored to our needs. I have no idea what features would be good to include, but having something that works better than vanilla AS as well as ASM68K is going to be very helpful.
If you end up modifying AS more, please for the love of god go and fix the numerous parsing bugs and some of the strange bugs preventing some projects at all. Such as some that plagued paddin/align on S3K projects where it would break for no reason. Having qn actual usable version of AS would be amazing.
Having examples of those issues would go a long way towards making it fixable.
So, I set up CI and daily snapshot autoreleases (for Windows, Linux, and OSX) and started doing some hacking. Please fill out bug reports for AS on that repository I forked, preferably with some example cases and I use for testing and I will try to fix them.
I will also be updating the disassemblies with these custom builds before closing this issue.
I don't think your repo has issues enabled. While I'm here, is there a chance you can edit AS to match its older behaviour to make this stuff unnecessary?
Hm, weird that issues was disabled. Anyway, enabled now.
Regarding the moveq/sign-extends... I am a bit torn. I like the warning AS generates because it allows catching some silly mistakes and forces you to be more explicit that yes, this is what you want. But on the other hand, it can be quite noisy, and the build setups used in the disassemblies treat warnings basically the same as errors, which is why that commit was needed in the first place.
Maybe an option to silence these kinds of sign-extension warnings would suffice?
I totally agree with @flamewing on the corrected moveq
behaviour.
The way moveq
worked in older AS revisions is completely broken and error-prone. It becomes apparent once you consider this simple example:
moveq #$A0-1, d0 ; copy $A0 words ...
.copy:
move.w (a0)+, (a1)+
dbf d0, .copy
The older versions of AS won't raise any warnings during assembly, while moveq
in this example will set register d0 to a different value than the instruction implies.
Instead of setting d0 to the value of $A0-1
, the compiled instruction will effectively set it to $FFFFFFA0-1
, because moveq #$A0-1
doesn't really exist due to the sign-extension.
This is completely incorrect and misleading behaviour, which leads to all sorts of hard-to-catch errors in your code.
The assembler must issue a warning when you're trying use moveq
with values it cannot represent instead of silently accepting those and producing broken code. Those warnings should be enabled by default.