BlitzMax on MSVC

BlitzMax Forums/BlitzMax Module Tweaks/BlitzMax on MSVC

René Damm(Posted 2009) [#1]
This isn't strictly just a module modification as it involves changes to BMK, too, but anyways...

I lately messed with interfacing BMax with a MSVC++ compiled DLL to which I don't have the sources and after a short and bloody struggle with MINGW figured that it would be easier to just take BMK and the BMax module sources and port the whole thing over to the MS toolchain (since these tools have become freely available, I think there is little incentive to stick to the brittle MINGW stuff anymore anyways).

So far it works, but frankly, it hasn't seen much testing yet.

If anyone is interested in this stuff, please leave a post here or drop me a line via email and I'll post the patches to BMK and the modules here.


Shagwana(Posted 2009) [#2]
To what advantage was this to be done for?

Are the MS tools better, and produce faster code?

If so, then this is something I think a lot of people would love. Me included.


xlsior(Posted 2009) [#3]
Hm.... Does the MS toolchain allow for the creation of 64 bit executables by any chance?

If so, that could be a very interesting addition...


markcw(Posted 2009) [#4]
[snip]


Brucey(Posted 2009) [#5]
Uh oh :-)

http://www.garagegames.com/my/home/view.profile.php?qid=4590


skidracer(Posted 2009) [#6]
Before BlitzMax was first released, I had bmk version talking to Microsoft tool chain, they had just released their C++ compilers for free which seemed mighty generous of them back then.

When/if mingw gcc4 releases proper it might be time to check out the two side by side for raw performance.


René Damm(Posted 2009) [#7]
Well, the main advantage is that you can now easily interface to C++ code compiled with the MSVC toolchain. With MINGW this really only worked in cases where you had virtual functions and could replicate the vtable layout; and even then, you couldn't call constructors and working with DLLs was just a big, big pain.

As for the code produced, the MSVC compilers are known to produce fairly good code, but I don't think that's as big a win here that could count as a real plus point especially since BMax's compiler goes directly to ASM so that the performance of your BMax code isn't affected by all of this in any significant way.

Whether the toolchain is "better" is sort of subjective; I personally don't have that high an opinion of MINGW while having fairly positive experiences with MSVC--plus it simply is the standard toolchain for the platform.

You *could* produce 64bit executables but compiling BMax for 64bits would probably require more than just flipping a switch. I suppose you'll be running into a fair bit of assumptions where pointers are taken to be 32bits, but that's just a guess. It probably is possible to do this port without too much work, though.

@Brucey
:)

Offtopic: Awesome work you're doing on BMax modules. wxMax is superb.