Re: [hatari-devel] Patch to fix disassembler

[ Thread Index | Date Index | More Archives ]

Am Sat, 12 Jan 2019 16:05:24 +0100
schrieb Thorsten Otto <admin@xxxxxxxxxxx>:

> On Samstag, 12. Januar 2019 15:40:30 CET Thomas Huth wrote:
> > Why is it not enabled for
> > 68020 and 68030, they could have a PMMU, too?  
> I think this is because Hatari has a separate option whether MMU is
> emulated for 030.

You can also have this in real life - CPU with PMMU or without, CPU
with FPU or without ... so I guess we should simply take the setting
into consideration here...

> >And why is the MC_PMMU macro the very same as the MC_FPU macro??  
> Don't ask me, i did not write that code ;)

Me neither ;)

> As mentioned, i could not
> figure out yet why CINVA/CPUSHA are not correctly disassembled. But
> they are not used that much, so i did not look much further.

Honestly, I also try to avoid that code. It looks quite ugly in my
eyes, with some functions like Disass68k() being bigger than 800 lines,
with nested switch-case statements etc. ... I fixed some issues
reported by Coverity and other static analyzers here in the past, and
partly it was a real pain... IMHO that code is pretty hard to maintain.

> Its also questionable whether you need 2 separate disassemblers. The
> output from the other looks a bit strange because it sometimes uses
> the internal names from generating the tables, but that could be
> fixed i guess.

If you ask me, I'd also rather get rid of the external disassembler
again, too... but that's ultimately a question for Nicolas who works
way more with disassemblies these days than I do.


Mail converted by MHonArc 2.6.19+