Re: [hatari-devel] WinUAE emulation bugs in 2013 / use of C++ compiler for Hatari build? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi Eero,
Am Tue, 5 Feb 2013 12:09:43 +0200
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> I was reading WinUAE forum threads and noticed few new fixed
> bugs mentioned against the latest version.
>
> LINK instruction bug (comment #8):
> http://eab.abime.net/showthread.php?t=67210
>
> MMU TBL flush in user mode (comment #164):
> http://eab.abime.net/showthread.php?t=46934&page=5
> (page 4 mentions even more bugs fixed)
>
> As WinUAE emulation seems still a fast moving target,
> I was wondering would it make more sense to build
> WinUAE CPU core version of Hatari with C++ compiler,
> and just the old UAE core version with plain C-compiler?
>
> I would assume that to ease the porting effort, hopefully
> significantly [1], and it would make potential later Qt UI
> integration easier as Qt is also C++.
The problem is not C++ here, it is the fact that WinUAE source code
changes a lot very fast - so it hard to keep track and it is even more
difficult to extract the CPU core changes from the huge check-ins.
So at least for the MMU030 part, I'd say let's way for the next official
WinUAE release, when everything has become a little bit more stable
there - and then we should do one big merge. Tracking each change in
the WinUAE repository is really too cumbersome.
Anyway, most of the CPU code is still plain C code, even it has been put
into a .cpp file, so I do not worry about C++ here.
> [1] Exception handling and potential future C++ features used
> in WinUAE wouldn't need to be redone. Issues that would
> need to be handled would then be "just" Windows & Amiga
> specific features, and adding Atari stuff.
WinUAE still uses the CATCH macro, so our longjmp implementation should
also work fine with new WinUAE code, no need to change anything here.
> Building one version of Hatari with C++ and another with C-compiler,
> would require CMakefile updates and hopefully only trivial changes
> to the current Hatari C code. Hopefully with the new C++ standard
> version that finally added C99 compatibility, there are less of those.
I remember some people trying to compile the Hatari C code with a
C++-only compiler a couple of years ago, and that did not work very
well or at all. So I really would like to avoid that if possible.
Thomas