mth:
RE: the ALT problem... I agree with fixing the bug at its origin, as that will benefit other applications. However, I'd suggest that it might make sense to use a temporary workaround in openMSX case an SDL fix isn't easy to obtain.
I tested SDLGL-PP with and without Aero enabled. No difference in CPU usage. For what it's worth, I ran kernrate against openMSX.exe and observed the following:
ProfileTime 429 hits, 65536 events per hit --------
Module Hits msec %Total Events/Sec
wow64cpu 172 3268 40 % 3449263
32Bit openmsx 75 3268 17 % 1504039
openmsx 75 3268 17 % 1504039
32Bit ntdll 41 3268 9 % 822208
32Bit nvoglv32 36 3268 8 % 721938
32Bit kernel32 24 3268 5 % 481292
32Bit dsound 6 3268 1 % 120323
===> Processing Zoomed Module wow64cpu.dll...
----- Zoomed module wow64cpu.dll (Bucket size = 16 bytes, Rounding Down) --------
Percentage in the following table is based on the Total Hits for this Zoom Module
ProfileTime 172 hits, 65536 events per hit --------
Module Hits msec %Total Events/Sec
TurboDispatchJumpAddressEnd 122 3268 70 % 2446570
CpuSimulate 48 3268 27 % 962585
CpuSuspendLocalThread 2 3268 1 % 40107
I was surprised to see all the the activity in wow64cpu.dll... I tried profiling the 32-bit iexplore.exe and in there the same module was at about 0%. So I'm not sure what that means. It would be great to have a native 64-bit binary, in any case.
I was reading the compilation instructions for Win32, and I'm inferring from that no Visual Studio support and no 64-bit compilation support. I'd actually be happy to at least take a look at what it would take to port openMSX to Win64 if I could build it from VS... Any ideas?
Wikipedia says "Wow64cpu.dll, which takes care of switching the processor from 32-bit to 64-bit mode". So for some reason, there are a lot of 32/64 bit mode switches. Maybe the OpenGL driver is 64 bit and the CPU mode has to be switched for every GL call openMSX makes?
I think the easiest way to try a Win64 build would be to use an x86_64 version of GCC. This already works on Linux, but not on Mac OS X, because of limitations in SDL.
Another approach would be to use the command line interface to the VC++ compiler from the openMSX build system. We already support GCC and Intel's C++ compiler, adding support for a third compiler shouldn't be hard. I don't know though if the code itself will compile, for example inline assembly syntax seems to differ per compiler. It is easy to disable inline assembly though: since openMSX compiles on non-x86 architectures too, there are #ifs around all assembly blocks, so if you edit one of the generated headers, you can disable inline assembly with a single line change.
Doing the build completely from VS would require to either manually run "gmake probe" or to do that as a pre-build step from the VS project. This would require to build all required libraries first. Usually this is done by the "3rdparty" feature of the openMSX build system, but if you want to avoid the command line and use VS exclusively, you'd have to make VS projects for all dependency libraries manually.
It would be very useful if someone would join us and help with a VS build! Especially if the free downloadable version of the compiler can be used as well. (Unless someone who owns VS, 'permanently' joins us...)
mth, Manuel:
I took a stab at installing the GNU tools referenced in the "Compiling openMSX" document. All was well until I got to MSYS, which does not run correctly on Vista x64. It errors during installation, and when launches it promptly spawns about 100 desktop windows and then closes them. Also, from reading various forum postings, the Windows x64 version of GCC looks a bit sketchy, while the 64-bit Microsoft compilers are very mature.
Using VS 2008, I've managed to compile x64 Windows DLLs and import libs for all required openMSX dependencies. Given that, it would be trivial to also generate static libs in order to build one big openMSX binary. Now, whether these builds actually work is another story - I saw hundreds of warnings about truncated data types that I didn't bother to chase down, since each would then become a (potentially unwanted) patch submission.
I also turned off the iconv dependency from within the xml library; like a number of GNU tools, it looked relatively Windows-hostile and I didn't want to waste time. Hopefully iconv isn't needed by openMSX.
The last hurdle is compiling openMSX itself. I got started on creating a VS solution for it, but quickly got bogged down by missing generated headers from the official build process (which, recall, I never got to work in the first place). So that's where I am today.
So are there any writeups on the headers the build process generates pre-compilation? Do these contain anything more than preprocessor definitions? I need to think about the best way to replicate this functionality from within VS.
Now, given a solution to that, I can certainly imagine creating an MSBuild-capable project that references external libs and builds openMSX. This should be usable from any IDE (including the free VC++ Express) as well as the command line. However, I'm not sure what the sustainable model is for maintaining that moving forward. Will someone on the team actually use it? In my experience, if something isn't being used by the developers, it's going to go stale pretty quickly.
Here you can find the files generated for 64-bit Linux. Changing these for Windows should require only minor editing, I think.
About sustaining the win64 build, it requires two things: integrating the win64 build with the rest of the build system and someone who regularly checks that the win64 build still works and fixes regressions that might occur from time to time.
Integration could be done in a number of ways. Waiting for MSYS to become usable on win64 requires little effort, but might take a long time. Running the openMSX build process without MSYS might be possible: it requires a few tools like gmake, sed and cat, but probably less than 10. A third option would be to replace the current openMSX build system by something that also runs on win64: I have been thinking about replacing the GNU Make based build system by a Python-based one (SCons or custom written), but so far none of the problems of the current system were severe enough to make it worth the effort to replace it.
Anyway, all of this is only relevant if building openMSX with the VC++ compiler is indeed possible. So let's focus on that first.
Well, I ran my first x64 compilation of openMSX with VC++. I ran into about a few different types of issues, none of which are going to be showstoppers, but some of which are slightly non-trivial. The question here for me is how deep the commitment is going to be from the openMSX developer community to get this working. I think the team would have to help with coming up with solutions to a few of these issues, then take some patches, then maintain discipline to not break VC++ in the future. If everyone is using GCC, that might be difficult, or the team might be understandably unwilling to take the plunge.
So the question is... Is it worth proceeding with this? I'm willing to spend some time on this, but I'll need both help and a reasonable commitment from the team to support the effort. The first step would probably to get things building for VC++ on x86 first.
Anyway, here's what I saw off the top of my head - about seven categories of issues:
1) Library stuff:
I haven't run anything yet, and I *might* be the first person to be building some of these things for Win64, so fingers crossed. But so far, so good.
The only real problem I've encountered so far is "Jack", which doesn't appear to have a Win32 build. I've tried using the "jackdmp" port, which at least appears to have the right headers, but I haven't built it yet.
2) Unixisms or C99isms in the openMSX sources: e.g. dirent.h, unistd.h, strings.h, M_PI, strcasecmp(), round(), strtoull(), getpid(), mode_t, S_ISREG, snprintf... Each of these probably has an optimal solution to be chosen from:
a) Finding an portable alternative.
b) Lifting Windows code that implements these from Cygwin, MinGW, etc.
c) Adding our own abstractions for these things in utils and using them throughout the code.
3) Definitions that mismatch with VC++'s, but the functionality is there:
a) __restrict__ to __restrict
b) __attribute__((aligned(16))) to __declspec(align(16)) -- although declspec precedes and attribute succeeds... Hmm.
4) Things that GCC supports that VC++ doesn't:
a) Allocation of stack arrays using non-constant expressions -- this can be emulated using _alloca or _malloca, although aligning on 16 is going to be interesting. This is likely to be the most disruptive change to the openMSX code, because there are *tons* of places where the code just does "int temp[x];" where x is some local.
b) One use of __uint128_t -- presumably we can use the uint128 class instead
5) Inline assembly. Microsoft's x64 compiler doesn't support inline assembly, although there is an x64 version of MASM. I turned off inline assembly for now.
6) Miscellanea I didn't understand:
a) Forced template instantiation -- VC++ won't compile these; not sure why they're needed.
b) typedef ArchiveBase<Derived> THIS; -- no idea what the intention is with these, but VC++ won't compile them.
7) On the order of 5000 warnings - most are C4244 and C4800.
I'd like to add that I have compiled one of the latest SVN binaries (dev8412) under Mac OS X 10.5.6 with GCC 4.0.1 without any problem.
I also managed to compile the latest source code from the SVN repository (0.7.0 - no dev number)
What is the purpose of the "CassetteJack" component ?
Does it allow to connect a tape recorder to the "line in" port of a soundcard and load directly the games in OpenMSX, like Virtual MSX / MESS ?
Components overview:
Emulation core: no
CassetteJack: no
SDLGL renderer: no
CassetteJack is optional and can be left out. cesco: that's indeed its purpose. Emulation core should be on "yes", otherwise it won't build. (THis means non-optional stuff is missing.)
mfeingol: if possible, you could join us on our IRC channel, which is a little easier to work with. Then we can try to tackle the problems one by one.