since some of us have moved over to using VS2010, not to mention the improved intrinsics and better code gen SSE optimisations (2008 was buggy in this regard), future builds of VBA-M for Windows may require the Visual C+ 2010 x86 runtime.
Â
If/when this change takes place, the readme.mfc will be updated with the VC10 download links.
Hello Squall Leonhart, about the VC++ 2010 runtime I don't think it will be necessary even building with VS2010.
Â
Right now the project files are set to use the /MT switch which creates executables linked to the static version of the runtime (multi-threaded, the single threaded version is long dead). I've just checked the latest executable build with Dependency Walker and there's no dependency on the C runtime. The only remarkable one would be the updated DirectX runtime (you can remove zlib from the readme file too as you're linking statically against it).
Â
I've just compiled SVN959 using the compiler provided in the Intel Parallel Studio 2011 through Visual Studio 2010 (changing some settings), the only dependency not included in Windows (7 in my case) is D3DX9_43.DLL; I've attached to this post a binary using SSE instructions. I'm using up to SSSE3 instructions for me, If you need a binary using a specific instruction set (e.g. SSE2 to allow the use of XMM registers) just tell me and I'll generate the binaries.
Â
Kind regards.
we build with what we have on hand, many of us have moved to vc 2010 already and have no interest using GCC.
Â
usage of Intel compilers is not likely as applications compiled by this and used on non intel processors have dramatically lower performance.
Yes, GCC in no option in this project and I was aware of that problem with Intel compilers (at least years ago it was crazy, I don't know how if behaves now). I only have access to the new Parallel Studio through my employers and was doing some tests.
Â
The important bit is that the binaries are being built with the runtime within the executable of VBAM, so there's no need for end users to install the VC runtime. If you changed the runtime library to multi-threaded DLL (/MD switch) and set MFC to use the DLL too, VBAM would be depend on msvcrXX, msvcpXX and mfcXX (so the redistributable package would be needed). Although the executable would be smaller, you'd lose the portability it now has.
Â
EDIT: The binary I posted above is not tied to any Intel processor. Optimizations and alternative paths for Intel specific processors were not selected.
That could explain the sudden balloon in size with vc10
That may be, It was the same with VS2008 as the runtime and standard C++ library were included too (no dependency on msvcr90.dll, msvcp90.dll or mfc90.dll) but runtime and MFC in VS2010 are slightly bigger (same as the other three but 100 instead of 90).
Â
I know some people for small programs link against the system CRT dynamically (no version number in the files) because it's already loaded and shared in memory so they get lower disk footprint, memory usage and startup. But if I recall correctly that's not possible in Visual Studio, nor desirable either for a big program. Those files are meant to be used for system components, they are not as complete/efficient as the ones provided with newer versions of VS.
Yes, GCC in no option in this project and I was aware of that problem with Intel compilers (at least years ago it was crazy, I don't know how if behaves now). I only have access to the new Parallel Studio through my employers and was doing some tests.
Â
it still is a problem, it was recently demonstrated on a the VIA Nano
Â
http://ixbtlabs.com/articles3/cpu/via-nano-cpuid-fake-p1.html
[img]<fileStore.core_Emoticons>/emoticons/ohmy.png[/img]/emoticons/ohmy@2x.png 2x" width="20" height="20" /> Impressive... even Agner Fog is involved!!! What a difference in the VIA Nano tests...
Â
I know there are some switches to add alternative paths or to target an specific Intel processor family. /Qax adds a processor specific auto-dispatched code path in addition to the default one (so you're already knowing the dispatcher will be in the executable if you use this one). /Qx overrides the /arch switch targeting an Intel processor family and the executable should only be used on those (e.g. /QxSSE3_ATOM generates code to be used in an Atom processor).
Â
The Parallel Studio provides a compiler too through the Parallel Composer which is the C/C++ compiler from Intel as generally released. The the latest version includes the v12 compiler (not available as of now, the latest standalone C/C++ compiler from Intel is v11); but there's already a post by Agner where he tells they haven't changed a thing in the new compiler [1].
Â
If you ever need to use the Intel compiler in page 130+ of Agner's optimizing C++ (at the time of writing, works with v12 compiler) there's a way to override the dispatcher detection [2].
Â
Thank you for pointing that out!
Â
[1]: http://www.agner.org/optimize/blog/read.php?i=49#127
[2]: http://www.agner.org/optimize/optimizing_cpp.pdf
Â
Â
EDIT: For completeness I made a question to Agner regarding the use of the Intel Compiler without the switches /Qx or /Qax [3]. Basically, if only /arch was used during compilation there's no dispatcher and the code generated will run fine in non-Intel processors. Unless special libraries are used by the project like MKL, TBB, ... (not the case in VBAM).
Â
I've been working on an installer for the VBA-M. As far as I can tell, it is complete. It will install the emulator to a folder inside the user's home directory, so it won't have issues with privileges and administrators. It will make all the folders and even makes the ini file for some preconfiguration, namely the folders where things go, like the save states, battery saves, screen shots, etc.
Â
If you wish, I can upload both the installer itself, which is a surprising 1.11 MB big as well as the NSIS code used to make it. It's easily customizable, able to be updated to reflect any new builds. It installer will install the latest SVN at the time, which is 965.
Â
As for uninstalling, just delete the folder the emulator was installed in.
installers are stupid. vba-m is portable for good reason.
