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



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/