Trying to emulate an entire 32-bit x86 CPU on a 32-bit x86 CPU is awkward because most of it is unusable by user code; segment registers, system registers, even ESP is restricted from being freely modifiable. A 64-bit CPU has an extra 8 general purpose registers to help get the job done.
The Mp3 Lame encoder very heavily uses the dosbox FPU functions (FPU_FLD_32, FPU_FST_32), it doesn't show the difference between Intel Xeon and Core 2 (coding times under 64-bit dosbox are very similar).
However, the Dhrystone benchmark performs much better, it clearly shows the disproportions.
That's what I linked to in the edit. I found it after when looking for other people's built versions.
Edit (Oct 21)
I managed to get this to compile (VS2019), and recompiled MUNT-SVN ( >2.3.0), FluidSynth( >1.1.6-noglib), SDL2 (2.0.11-snapshot), zlib (1.2.11), libpng (1.6.38-SVN snapshot), in 64-bit in a static build.
C Preprocessor settings
Intel(R) Core(TM) i5 CPU M 450 @ 2.40GHz
dosbox-svn-r4296, gcc-4.9.4, x86_64, (the second result with the patch applied)
VAX MIPS rating: 115.27 116.38
PCBench: 70.6 75.4
quake 1.06 with sound, demo1
320x200: 102.5 107.1
800x600: 28.4 32.8
Last edited by latalante on 2019-12-06, 11:47. Edited 1 time in total.
I tested the dosbox-staging version yesterday and the results were clearly lower than my build.
I upload my compilation here if anyone wants to compare. https://drive.google.com/file/d/1L12wqanCgboj … iew?usp=sharing
It was built under the new version of the C library (glibc-2.30) and requires it. Under Linux, compatibility only works up.
Downward compatibility can be maintained by starting it with loading the necessary libraries.
If you have glibc-2.30, then just run like this: