Re: [hatari-devel] The external disassembler is now really external |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] The external disassembler is now really external
- From: Thomas Huth <th.huth@xxxxxxxxx>
- Date: Sun, 28 Aug 2022 10:48:07 +0000
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1661683690; bh=k6LqK6oyoei6ajLgHdAWR/+tJNVoN1VWdhHdVuBPlOQ=; h=Date:From:To:Subject:From; b=nvNNder8d+OqyuzbwL6uzNGWitRCRQSX58OVvv+3XJpXJIGl/EIhsSxK/tkCq+4Ay HPErBzFcCqpz7KNXxNqDAtrU4XEX31Wn9tD3OGszl58r0kcfHE1h+e2lKTpJC7eiWs p1RcxvSsld40ELnu4TQJLerCXmzAZYmg4LG5D/5CQUTnnXTmiumH3R/7om6cGZTGyC y6xoM55IGAt3f6zfzcXVJLNIEgTuJghs0QM5iX9XdOfxaAMfi/IU+ps7xlEdqASkhh uOwGZsXh3+Q3GwgIuU23cgAapnLwduSQozBQWQAlFAquELFk56KFjfMZR5qdeQMsti 2PLQRuyAnWu4g==
Am Sun, 28 Aug 2022 12:03:28 +0200
schrieb Thorsten Otto <admin@xxxxxxxxxxx>:
> On Sonntag, 28. August 2022 10:29:47 CEST Thomas Huth wrote:
> > Done now, FNOP here:
>
> To be honest, i don't quite understand the decision to replace the already
> working solution, by a bloated library (none of the other architectures that
> are supported by capstone are needed in Hatari), which is also buggy (atleast
> for m68k)?
We already have a disassembler in Hatari. Maintaining a second one is
just a waste of resources and space:
1) The previous solution bloated Hatari. The code was more
than 2300 lines of code that now have been removed.
2) We had many cases in the past where the previous disassembler also gave
wrong instructions. Since the code was very hard to maintain (huge
functions with a lot of indentation levels), these were a pain to fix.
3) Since the code was written in a bad maintainable way, it was also a pain
to fix compiler warnings each time a new GCC came around and found new
issues.
At least for me, that disassembly code was more of a nuisance than being a
benefit. Even if Capstone is not perfect yet, people from other projects
will contribute there, too, so the pain of maintainence is (hopefully) much
lower here.
Thomas