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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 19/10/2022 à 23:34, Eero Tamminen a écrit :
> Hi,
>
> I've pushed it now, with doc updates.
>
> Please check out the new WinUAE CPU disassembly options!

>>> 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.
>>>

Hi

regarding the recent DISASM_FLAG_xxx that were added to WinUAE for more 
control on the output, I think I just forgot to look at what those flags 
did when I merged the changes, so our 68kDisass.c was not updated to use 
these flags. thanks for doing it.

Nicolas


> 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