GP2X Dosbox Dynamic Recompiler Backend

[M-HT]

Hi,

after some difficulties I have finally got a working (hopefully) DOSBox dynamic recompiler backend (or three).

You can find the source and some instructions here.

Before you get happy about faster dosbox, here are couple notes:
- to use the dynamic recompiler, core must be set to dynamic or auto in dosbox.conf
- the dynamic recompiler framework in DOSBox is not really suitable for arm processors - different recompiler (for arm) would be better, if someone was willing to write one
- I don't know if it's actually faster with dynamic recompiler than without it (didn't seem so). So the important question is: How to benchmark whether and how much is it faster ?

Edit: added the dynamic parameter

 

[Exophase]

Hi,

after some difficulties I have finally got a working (hopefully) DOSBox dynamic recompiler backend (or three).

You can find the source and some instructions here.

Before you get happy about faster dosbox, here are couple notes:
- to use the dynamic recompiler, core must be set to auto in dosbox.conf
- the dynamic recompiler framework in DOSBox is not really suitable for arm processors - different recompiler (for arm) would be better, if someone was willing to write one
- I don't know if it's actually faster with dynamic recompiler than without it (didn't seem so). So the important question is: How to benchmark whether and how much is it faster ?



What did you do to fix the problems you were having? I imagine just measuring fps for something known to be under fullspeed, but not drastically so, would be a good enough test. Also something with sound off and that uses simple, low resolution graphics if at all possible. The best thing would probably be a CPU stress test of some sort ran at command line.

 

[M-HT]

What did you do to fix the problems you were having? I imagine just measuring fps for something known to be under fullspeed, but not drastically so, would be a good enough test. Also something with sound off and that uses simple, low resolution graphics if at all possible. The best thing would probably be a CPU stress test of some sort ran at command line.

One problem was in the thumb recompiler where I emitted wrong instruction (sub r0, r0, #2 instead of sub r0, r0, #1).
The other (bigger) problem was with register allocation. I assigned FC_RETOP (register that holds function return values) and FC_OP1 (register that holds the first parameter) the same register - r0 (the same as in arm abi), but the recompiler framework uses FC_RETOP in some cases as a temporary register (for example in 3 parameter instructions like shld) - the result was that the register r0 (FC_OP1) was thrashed.
So I assigned FC_RETOP a different register (not used elsewhere) and the problem was solved. This unfortunately induced some overhead (like copying the value from register r0 into another register after function return), but nothing major.

Some concrete benmark would be helpful - it's been a long time since I benchmarked something in DOS

 

[slaanesh]

Hey this sounds really promising. I will try this out and see how it goes.

 

[Pickle]

Hi,

after some difficulties I have finally got a working (hopefully) DOSBox dynamic recompiler backend (or three).

You can find the source and some instructions here.

Before you get happy about faster dosbox, here are couple notes:
- to use the dynamic recompiler, core must be set to auto in dosbox.conf
- the dynamic recompiler framework in DOSBox is not really suitable for arm processors - different recompiler (for arm) would be better, if someone was willing to write one
- I don't know if it's actually faster with dynamic recompiler than without it (didn't seem so). So the important question is: How to benchmark whether and how much is it faster ?



Yeah!
Thanks for finishing it. Ive have a pretty good idea on how some games run speed wise. So I will be sure to give a shot and post back if i see any improvements.

Many many thanks for the effort.

 

[Pickle]

Update: Ive compiled in the changes, i went with thumb version. I didnt quite follow your comments on the others (one was fast but had slower code?)

I guess in general there doesnt appear to be a huge speed increase. Some of the games that do run seem to run a little bit better. PC Sound is clearer, I used to get buzzing after a sound played but thats seems have gone away.

Also are you sure the parameter dynamic for the core doesnt work? I tried it and it did run, I dont know if it fell back to some other core.

 

[M-HT]

Update: Ive compiled in the changes, i went with thumb version. I didnt quite follow your comments on the others (one was fast but had slower code?)

The thumb version is prefered. The others are arm versions, and I only put them there because I started working on them before I decided to do the thumb version.

Also are you sure the parameter dynamic for the core doesnt work? I tried it and it did run, I dont know if it fell back to some other core.

I looked at it closer and you are right, the parameter dynamic works - I thought it was only for x86 recompiling core, but I was mistaken (I also updated my first post).

 

[Pickle]

M_HT you said you modified the cache size would increasing this give better performance? What kind of size did you change it from?

 

[M-HT]

M_HT you said you modified the cache size would increasing this give better performance? What kind of size did you change it from?

I don't think so. At least not a noticable increase.
I changed two values in core_dynrec.cpp - CACHE_TOTAL and CACHE_BLOCKS

Original values:
CODE
#define CACHE_TOTAL (1024*1024*8)
#define CACHE_BLOCKS (128*1024)


Modified values:
CODE
#define CACHE_TOTAL (1024*1024*4)
#define CACHE_BLOCKS (64*1024)

 

[Pickle]

Ive done a little bit more of testing and I think I can see the improvement. 2 examples are Keen 4 and Pinball Dreams. I think with the dynarec Im able to increase the cycles more than before which is giving a better frame rate. For example our frame counter, which counts any frame updates would give about 25 frames in pinball dreams, now im able to get numers in the 30's.
Its not a big increases but its something.

 

[pupnik]

- the dynamic recompiler framework in DOSBox is not really suitable for arm processors - different recompiler (for arm) would be better, if someone was willing to write one
- I don't know if it's actually faster with dynamic recompiler than without it (didn't seem so). So the important question is: How to benchmark whether and how much is it faster ?

THANKS M-HT!

15:17 < c2woody> the problem is that they needed two years to even fill out that simple recompiler stuff
15:17 < c2woody> so i doubt anybody will write a real recompiler, if there'd be anybody capable of doing it
15:17 < c2woody> and then it'd need huge loads of time...
15:21 < c2woody> not like the dynamic core, which can use a lot of the host cpu
15:21 < c2woody> but the portable dynrec core is meant to be a start for further work
15:22 < c2woody> so you can take out higher-level things and optimize them

I don't have time atm to work on this, and I'd be pretty lost. But when I do manage to incorporate your changes into my build (for OMAP2420 devices) i will do some testing (reporting of max possible cycles in various games, timedemos, not so much artificial benchmarks)

Thanks also for the clear website showing what was changed. I'd love to get dosbox up to about a 12mhz 286 someday.

Btw has anyone had success using a dosbox built for gp2x to run when compiled with -fgenerate-profile? It just crashes for me.

 

[Pickle]

- the dynamic recompiler framework in DOSBox is not really suitable for arm processors - different recompiler (for arm) would be better, if someone was willing to write one
- I don't know if it's actually faster with dynamic recompiler than without it (didn't seem so). So the important question is: How to benchmark whether and how much is it faster ?

THANKS M-HT!

15:17 < c2woody> the problem is that they needed two years to even fill out that simple recompiler stuff
15:17 < c2woody> so i doubt anybody will write a real recompiler, if there'd be anybody capable of doing it
15:17 < c2woody> and then it'd need huge loads of time...
15:21 < c2woody> not like the dynamic core, which can use a lot of the host cpu
15:21 < c2woody> but the portable dynrec core is meant to be a start for further work
15:22 < c2woody> so you can take out higher-level things and optimize them

I don't have time atm to work on this, and I'd be pretty lost. But when I do manage to incorporate your changes into my build (for OMAP2420 devices) i will do some testing (reporting of max possible cycles in various games, timedemos, not so much artificial benchmarks)

Thanks also for the clear website showing what was changed. I'd love to get dosbox up to about a 12mhz 286 someday.

Btw has anyone had success using a dosbox built for gp2x to run when compiled with -fgenerate-profile? It just crashes for me.

I did the profile for some of the Gp2X builds. Its not really worth the time, the performance gain really isnt there.
I use the open2x toolchain in linux.