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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

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