Re: [hatari-devel] WinUAE CPU core disassembler output options

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

On 8.10.2022 16.51, Christian Zietz wrote:
Eero Tamminen schrieb:
Attached patch adds preliminary support for controlling UAE disassembly
output.

It allows configuring all CPU core disassembly flags except the
DISASM_FLAG_ABSSHORTLONG one for address length of shorts (8 vs 4 hex
chars).

This was inspired by Christian's complaint about its too cluttered
output at atari-forum, and remembering that Toni added already some
output options to CPU core disassembler.

Comments?

I just tested your patch and highly appreciate it. Thank you! It allows
me to configure the UAE disassembly to be much more to my liking. And
yes, I'm aware that everyone has their personal preference; therefore,
it's good that it can be configured from within Hatari now.

I'm also interested whether anybody has an issue with the small change to the ext format to make disassembly outputs more consistent (especially when omitting the instruction hex-words).


One thing I haven't figured out, though: Which bit-flag can be used to
disable the "(T)" or "(F)" annotation following conditional branches? As
it is (understandably) based on the *current* state of the CPU flags, I
find it confusing and would like to suppress it.

Unfortunately all of that extra output from the WinUAE CPU core does not seem to be configurable, only some of that.

For example of the three places outputting those true/false CC flags, only one checks disasm output flag:
https://git.tuxfamily.org/hatari/hatari.git/tree/src/cpu/disasm.c#n2396

There are also several places which unconditionally output that extra " == <address>" info:
* https://git.tuxfamily.org/hatari/hatari.git/tree/src/cpu/disasm.c#n460
* https://git.tuxfamily.org/hatari/hatari.git/tree/src/cpu/disasm.c#n480
* https://git.tuxfamily.org/hatari/hatari.git/tree/src/cpu/disasm.c#n1692
* https://git.tuxfamily.org/hatari/hatari.git/tree/src/cpu/disasm.c#n2396

Which is rather annoying.

But at least the options I added for controlling WinUAE CPU code "disasm_flags" reduces some of that output.

I hope there are eventually suitable checks in the above listed places, but somebody more familiar with WinUAE CPU needs first to explain why they're currently missing from it.


(And as earlier mentioned,having option to separate opcode mnemonic and its operands to separate columns could greatly improve disassembly readability.)


	- Eero



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/