asar
asar copied to clipboard
Warn or error when opcode length is ambiguous
Asar will currently try to "guess" opcode length in cases where it's ambiguous. Stuff like CMP #!some_define
in my experience usually results in word size being assumed, which has led to numerous crashes, as it's easy to forget to specify the length and get some second opcode thrown in.
In my opinion, rather than "guessing" the length and potentially failing with very bad consequences, asar should throw an error or at the very least a warning in this case, because it can be ridiculously annoying to debug a crash resulting from the assembler making a wrong guess while it would be incredibly easy to fix if it told you that it were in fact making a guess in the first place.
If there's already a way to make asar do this please let me know, I couldn't easily find a way to turn anything like this on in the manual and found no mention of it in the changelog.
It's been brought to my attention that one can indeed warnings enable W1013
and have this behavior throw a warning. I assume there is some reason that it's not on by default, but I'd like to suggest both mentioning the ability to turn this warning on in the "Opcode Length Specification" section of the manual and considering turning this on by default in future versions (especially if a 2.0 release happens at some point).
I want to add, that this warning is not enabled for the BIT
instruction.
BIT #$20
is not warned, although it depends on the m
flag
@Underrout this issue is not resolved, can you please reopen it?
[1:04 AM]p4plus2: !rb as
warnings enable W1013
bit #0012
[1:04 AM]BOT randombot999:
<input>:3: warning: (W1013): Implicitly sized immediate. [bit #0012]
89 0C
Looks warned to me?
There has been no new commits since my comment in october. In fact the last commit was in juni 22 (https://github.com/RPGHacker/asar/branches) so either I made a mistake while posting my comment or something weird happened. I would say it's me to blame so the issue can be closed. If I happen to reproduce my issue, I will open a new one.
Thanks
I will say there are some ways to mitigate this problem in the first place and talks are ongoing to reduce the ambiguity anyways. But those are changes I would not expect to see until 2.0 as they may not be appropriate for 1.x