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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

I've pushed it now, with doc updates.

Please check out the new WinUAE CPU disassembly options!


	- Eero

On 18.10.2022 2.39, Eero Tamminen wrote:
> Unless somebody has objections, I'll push this in day or two.
>
> There's ample time to improve debug options support on WinUAE side after 
> that, before next Hatari release.
>
> On 10.10.2022 1.17, Eero Tamminen wrote:
> > 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