GP2X Dosbox Dynamic Recompiler V2

[Pickle]

Update 2: Ok ive tried and I cant say I see a difference, the fps counter is all over the place sometimes. I hope I compilied it correctly. It feels the same as the last version.

4% speed increase (in my benchmark) is not so big, and in the game you are testing, the increase is probable less than that, so the difference may not be noticable.
Other thing is - you say, that the fps counter is all over the place sometimes, was it the same in the previous version or is it only in this version?

No its always been that way, i think its just from the way dosbox works. Basically since it only draws pixel changes the fps will go down if nothing changes. In general the average fps appears to be the same, so its pretty hard to see the 4%, since it would only be a fps or 2 increase. Thats why ive been using pinball fant. as my game benchmark, cause it moves quite a bit. But no worrys, every little bit adds up.

I've been following this thread with some interest and have a couple questions - which I may have asked already but I'm happy to ask them again:

1). How much RAM does DOSBOX need to run? Although a simple question, I know there will be a complicated answer.
a). If you are emulating a smaller machine, say 640KB, how much RAM is required to run this?
B). Can DOSBOX be compiled to leave things out that are not required to decrease the size of executable? ie. If you don't want any fancy sound-card support for instance.
c). Basically is it possible to get DOSBOX running in 8MB of RAM?

B) yes
c) I don't guarantee it, but it may be possible. Of course only without dynamic recompiler, because it requires lot of memory for translation cache.

These questions are probably better asked in the dosbox forum - you might get better answers there.

There was a thread in the dosbox forms about proting to a nokia phone i think. Basically the problem was the small size. Take look at the PORTING doc in the source code for memory saving changes. GP2X only uses the TLB change since it saves a massive 15 meg.
Also the smallest extended memory you can have is 1 mb, ive read that somwhere.

 

[slaanesh]

c) I don't guarantee it, but it may be possible. Of course only without dynamic recompiler, because it requires lot of memory for translation cache.

A pity that the it would be without dynamic-recompilation as this would be one of the main reasons for doing it in the first place on the target I had in mind.

How much RAM is required for the translation cache? Is this dependent of the emulated machine's configured RAM size?

I'll also have a look at the DOSBOX forums

 

[M-HT]

c) I don't guarantee it, but it may be possible. Of course only without dynamic recompiler, because it requires lot of memory for translation cache.

A pity that the it would be without dynamic-recompilation as this would be one of the main reasons for doing it in the first place on the target I had in mind.

How much RAM is required for the translation cache? Is this dependent of the emulated machine's configured RAM size?

I'll also have a look at the DOSBOX forums

Technically, you might be able to use the dynamic recompiler, because the size of translation cache is configurable, but to fit it all into 8MB means the size of translation cache would be quite small. And this means that the speed increase of dynamic recompiler would be lower or it might be even slower than simple core depending on the size of the translation cache. Nothing is stopping you from trying it, but the results may not be up to your expectations.

 

[Pickle]

FYI for anyone interested M-HT ARM backend is being added to the offical dosbox code base. They arnt adding the latest version since it reduces performance for the x86 backend, but they are adding the older cleaner version.

 

[M-HT]

FYI for anyone interested M-HT ARM backend is being added to the offical dosbox code base. They arnt adding the latest version since it reduces performance for the x86 backend, but they are adding the older cleaner version.

I rewrote the latest version to make it simple to integrate into official dosbox code (without loss of speed) and it was already commited to dosbox cvs.

I also got some ideas that may bring more speed, but I have to implement and test them first to see the results.

 

[slaanesh]

Thanks for the updates. I'm always keen to read about optimizations.

 

[M-HT]

I rewrote the latest version to make it simple to integrate into official dosbox code (without loss of speed) and it was already commited to dosbox cvs.

I also got some ideas that may bring more speed, but I have to implement and test them first to see the results.

I changed the recompiler to match the dosbox cvs and implemented the new ideas and the result is on this page.
I was hoping for more speedup, but at least it's something.

Here are the results of benchmarking the various recompilers against the simple core:

risc_armv4le-thumb-iw.h - new thumb version (requires -mthumb-interwork switch) - ~55% speedup
risc_armv4le-thumb-niw.h - new thumb version - ~51% speedup
risc_armv4le-o3.h - arm version - ~38% speedup
risc_armv4le-s3.h - arm version - ~38% speedup
risc_armv4le-thumb.h - old thumb version - ~26% speedup

 

[Pickle]

I rewrote the latest version to make it simple to integrate into official dosbox code (without loss of speed) and it was already commited to dosbox cvs.

I also got some ideas that may bring more speed, but I have to implement and test them first to see the results.

I changed the recompiler to match the dosbox cvs and implemented the new ideas and the result is on this page.
I was hoping for more speedup, but at least it's something.

Here are the results of benchmarking the various recompilers against the simple core:

risc_armv4le-thumb-iw.h - new thumb version (requires -mthumb-interwork switch) - ~55% speedup
risc_armv4le-thumb-niw.h - new thumb version - ~51% speedup
risc_armv4le-o3.h - arm version - ~38% speedup
risc_armv4le-s3.h - arm version - ~38% speedup
risc_armv4le-thumb.h - old thumb version - ~26% speedup

What is the increase since the last version? I thought the last version was the one that required -mthumb-interwork switch?

Also your post refers to the CVS code, but the webpage refers to release 0.72-5, im confused on which one is needed. I assuming you meant the cvs for both since the page you linked only has 3 files? (sorry missed one of those is a zip)

 

[M-HT]

What is the increase since the last version? I thought the last version was the one that required -mthumb-interwork switch?

Release 0.72-5 uses risc_armv4le-thumb-niw.h (the older equivalent), which doesn't require -mthumb-interwork switch and this went from ~45% speedup to ~51% speedup.
Later I put on my webpage version which requires -mthumb-interwork switch (older version of risc_armv4le-thumb-iw.h) and this one went from ~49% speedup to ~55% speedup.
Put together, the release 0.72-5 went from ~45% speedup to ~55% speedup.

Also your post refers to the CVS code, but the webpage refers to release 0.72-5, im confused on which one is needed. I assuming you meant the cvs for both since the page you linked only has 3 files? (sorry missed one of those is a zip)

You need the 0.72-5 release. I will put the changes from cvs version on another page later - hopefully it will be accepted into cvs.

 

[Pickle]

Ok i think i have a version with the latest changes. Some warnings although are coming acroos like:
CODE
Warning: dosbox.o supports interworking, whereas dosbox does not

Do you get these when you build?
This is my configure statement:
CODE
./configure --prefix=$OPEN2X --with-sdl-exec-prefix=$OPEN2X --host=$HOST --target=$TARGET --build=`uname -m` CPPFLAGS="-I$OPEN2X/include" CXXFLAGS="-O3 -fmerge-all-constants -ffast-math -funswitch-loops -mcpu=arm920t -mthumb-interwork" LDFLAGS="-s -static -L$OPEN2X/lib" --enable-core-inline

 

[M-HT]

Ok i think i have a version with the latest changes. Some warnings although are coming acroos like:
CODE
Warning: dosbox.o supports interworking, whereas dosbox does not

Do you get these when you build?

Yes I get them too, but everything works, so I ignore them.

 

[Pickle]

Ok i think i have a version with the latest changes. Some warnings although are coming acroos like:
CODE
Warning: dosbox.o supports interworking, whereas dosbox does not

Do you get these when you build?

Yes I get them too, but everything works, so I ignore them.

awesome, the only thing I was planning to do was link in Senor Quack latest SDL so we will have USB keyboard support and I will put out version 6.

 

[slaanesh]

With USB keyboard support, this is going to be a pretty awesome release!

 

[Pickle]

With USB keyboard support, this is going to be a pretty awesome release!

Well if I can get it to run, my build has a SDL snag at the moment.

 

[M-HT]

I added a small bugfix to my page with the latest changes.
It actually works without the fix, but it's better to use the fixed version.

 

[Pickle]

I added a small bugfix to my page with the latest changes.
It actually works without the fix, but it's better to use the fixed version.

Do you think your done this the last change for a while? Im ready to put out a new version, but I will wait if you think you will have more updates.

 

[M-HT]

Do you think your done this the last change for a while? Im ready to put out a new version, but I will wait if you think you will have more updates.

I'm not planning any more changes - unless there's some bug in the dynamic recompiler, which I don't know about.

 

[pupnik]

Do you think your done this the last change for a while? Im ready to put out a new version, but I will wait if you think you will have more updates.

I'm not planning any more changes - unless there's some bug in the dynamic recompiler, which I don't know about.

I'm building for omap3640 atm with

./configure --enable-core-inline --disable-dynamic-x86 --enable-dynrec --disable-fpu-x86 CXXFLAGS="-O3 -fmerge
-all-constants -ffast-math -funswitch-loops -pipe -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -ftree-vectorize -fsingle-precisio
n-constant -mthumb-interwork"

and getting
{standard input}: Assembler messages:
{standard input}:3732: Warning: partial line at end of file ignored
{standard input}:2669: Error: undefined local label `.L525'

Any idea what's causing it? the default CFLAGS don't seem to be a problem

 

[Pickle]

Do you think your done this the last change for a while? Im ready to put out a new version, but I will wait if you think you will have more updates.

I'm not planning any more changes - unless there's some bug in the dynamic recompiler, which I don't know about.

I'm building for omap3640 atm with

./configure --enable-core-inline --disable-dynamic-x86 --enable-dynrec --disable-fpu-x86 CXXFLAGS="-O3 -fmerge
-all-constants -ffast-math -funswitch-loops -pipe -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -ftree-vectorize -fsingle-precisio
n-constant -mthumb-interwork"

and getting
{standard input}: Assembler messages:
{standard input}:3732: Warning: partial line at end of file ignored
{standard input}:2669: Error: undefined local label `.L525'

Any idea what's causing it? the default CFLAGS don't seem to be a problem

I dont think you set the dynarec type check config.h for #define C_TARGETCPU ARMV4LE

 

[nkldmt]

does anyone have any idea why dosbox works only through the compat mode on an f200 with open2x dr7?