So yeah, it is!
That what is done in the version you will check now:
- it is latest _official_ svn's DOSBox code with the latest commit of a few days ago
- it is built now over SDL2: that written not by me, its some patch done by others, which is not in the main repo at the moment. It fixes a lot of, gazillion, of SDL1 bugs, so chances it will help us are high. At least from first checks it surely help with keyboard layout issues, random freezes, etc.
- it is built now with a dynamic PPC recompiler! Yeah! It is! Our majesty kind of JIT!
New dynamic recompiler means all you need now it's in the config file, have those strings:
core=dynamic
cycles=max
Results are good (maybe not _that_ good, but still).
PCPBench report on my machine just 4.2 fps with normal, and 15.2 with dynamic, so its 3.5-4 times speedup.
Also, I tried Mortal Kombat 3 game: with "normal" its playable, but I can see that its around 25 fps maybe. With "dynamic" it all looks pretty fluid like it 60 and more fps.
Tried to play also in doom, extreme pinball, and pinball illusion: not sure if there are big differences, but at least doom feels better surely.
Quake1 at least playable with "dynamic" as with "normal" it slow like amiga1200 on my x5k (strange ..)
Of course, it didn't do by me, it was done by some other person for PPC-macs, and by some luck, I was able to use it for our build too with some small change (see in some other thread some help from Rigo about how to allocate executable memory).
That what the author wrote about:
Quote:
Some comments on the changes:
- I had to name the FPU_Rec struct so it could be forward-declared in risc_ppc.h (having a dedicated register pointed to it helps FPU heavy code).
- Removed some unneeded WORDS_BIGENDIAN guards in the self-modifying code detection, they weren't needed as the additions aren't meant to overflow between bytes.
- Made dyn_run_code() get called before dyn_return(BR_Link1/BR_Link2) and shuffled their locations a bit. The reason for this is that the PPC dynrec generates its epilog once in gen_run_code() and then puts a jump to it whenever gen_return_function() is called, rather than emitting a full epilog every time. If dyn_return() was called before dyn_run_code() the address of the epilog is unknown.
- Added missing cache_block_before_close()/cache_block_closing() calls for those blocks, since they were missing.
- The dynrec decoder wasn't differentiating between little-endian (host) memory access and regular memory access. I added new functions where necessary (hopefully caught them all) and aliased them to the regular functions when WORDS_BIGENDIAN is not defined.
- dyn_ret_near() was bugged, it tried to write a dword to ®_ip which overran on big-endian.
- it includes endian fixes for drive_fat.cpp to work on big-endian (including fixing a bug that allocates one too many clusters when a file's length is a multiple of the cluster size) and makes use of GCC's bswap builtins (which for PowerPC translate to lwbrx/stwbrx) for host memory access.
That one of course also done not by me, but I apply it anyway, even if I do not know how much is need it for us.
Now, before anyone throws all the question, there are answers:
1). No, it's not the DosBox-X project. DosBox-X is maybe interesting once the author will fix all newly introduced issues and big-endian differences. It also has lots of bugs. New bugs, which original DOSBox didn't have. So...
2). No, Corto's endian changes not in there, because it built now with PPC recompiler, which means that everyone should use that one instead. But maybe, I will apply Corto's patches as well, if there will be real needs and it will help at top of what we will have now with dynamic recompiler.
3). No, the SDL2 version is not faster. Is even can be a little bit slower. Of course, I talk about "normal" CPU choice, when it dynamic, its all will be faster of course. Is it an issue with SDL2, or with "how it added to DOSBox", dunno.
So, if anyone willing to test/help, that what we need now:
1). test as many as possible stuff, with "normal" and "dynamic" and report issues that happens only with "dynamic" so I can report them to the author in the hope he will fix it.
2). check if my build has issues that os4depot build didn't have. I think there is at least one issue that can be with the "midi" part, but I not sure. More users with DOSBox knowledge need to check it.
And there is just a binary, so don't ask how to set up it, where .conf files, etc: if you use DOSBox already you know where-what-when, just use new binary and change "core" and "cycles" to use dynamic:
Grab it from there:
http://kas1e.mikendezign.com/aos4/dosbox/jit/dosbox_jit_v1.lhaI will also create a repo on my github acc with all that stuff applied, so together later we may do something more of it as well.
Edited by orgin on 2020/1/20 17:10:12