Working On A Dynarec For Gpsp For The Gp2x


zodttd: YOU ARE THE WIN.



I have a spare computer sitting around, which dual-boots Linux and Windows. I could give you NFS/remote desktop/SSH access to it to do development work. It's a fairly fast Pentium III with 340mb of RAM (got it for $5 at a garage sale, hee). If you want access, just tell me.



To say it again: YOU ARE INCREDIBLE. If you get this working completely, you'll be like GPJesus.



:lol:
 
Thanks for the continued progress reports!
I'm really optimistic about this. Even if the next build you release isn't fullspeed, this project is moving in the right direction.
This could be the "killer app" for the 2x. I know it will be the emulator I will use most when it is released.
 
The anticipation of reading this thread everyday is killing me, can't wait for the release. :p Great work and thanks a bunch
 
KingCheese posted on Feb 13 2007 at 04:25 PM said:
Hey zodttd, good work ... and keep your head up ;)
Sorry for that question, but can you use the dynarec also for the psx4all emu??
Because it would be awesome, playing psx ~10fps faster. :)

You might not have been around, but he tried a dynarec for PSX4ALL... it turned out something else was the bottleneck on the GP2X. Zod and the PSX4ALL team intend to rewrite the emulator more or less from scratch eventually, but one thing at a time I guess :)
 
Last edited by a moderator:
slaanesh posted on Feb 13 2007 at 01:58 PM said:
DanSolo posted on Feb 13 2007 at 10:49 PM said:
Why can't you just post the C to someone with a faster computer and let them compile for you?
I can answer this one. Developing is kind of interactive. There's an iterative cycle of compile, test, change, compile, test, change, etc. :)

Sounds more like trial & error to me :p (Well, that's how i work anyway :p)
 
Last edited by a moderator:
Hmm... <_< seeing is believing...
What ever the outcome may be, reading the progress posts of Zodttd are always yammy yammy :)
 
zodttd posted on Feb 13 2007 at 05:24 PM said:
Yay! I got to speak with Exophase. It landed up that the version I was originally using for the dynarec was outdated. I am getting the updated version now. Things will work a lot better I'm thinking. :)

I will give a status update on the dynarec in a few hours. We might have something working that quickly. You never know with dynarecs, I'm due for getting lucky with one by now. Heh. :)

Since I already converted this dynarec to work with ARM, redo'ing it will be much easier. I have most of it done already to some extent.

YAY!

Cool that sounds encouraging. It is good that exophase will give you some tips as sometimes figuring out someone elses code (GPsp). can be hard

Good luck and thanks again for the work and progress info.
 
Last edited by a moderator:
zodttd posted on Feb 13 2007 at 03:51 PM said:
Just to elaborate...A dynarec is a method of generating "bytecode" on-the-fly, meaning during run-time. This bytecode is executed and cached. When a codeblock is requested again, the cache can be checked to see if it's already been translated and has the bytecode generated within it. If it has, it's instantly executed, saving time and generally being much faster. This is in comparison to an interpreter which everything is set during the compile, and during runtime everything must be translated every time. Imagine a counter doing "a = a + 1" and having to go through a lengthy interpreter code to extract that information just to repeatedly increment the variable "a" by 1. In a dynarec this would be done as if it were running natively in ARM by using the ARM instruction set and just incrementing that register by 1. Much faster. :)

Problem is, this dynarec is giving me a hard time. I suppose it's because I'm trying to wrap the MIPS dynarec instead of completely starting from scratch. What a pain. ;P

Time to talk to Exophase and see what we can work out. I'm so close though, it will get done.

Interesting. The only thing I knew so far was, that the mysterious Dynarec was the "thing that does not had worked for the PSX Emu in the End" :lol:
When this thing will work, could the GBA Emu (in theory) run faster then the SNES-Emus (with transparencys) ? Because it sounds, that the GBA emulation don't have such problems with transparencies or am I wrong?
 
Last edited by a moderator:
Man, reading this every 30 minutes to see if anything new has happened is killing me! I wish it could be done (don't we all) but I know your doing your best and believe me, I really do appreciate it. I'm just itching for a release! :)
 
reiboul posted on Feb 10 2007 at 07:27 PM said:
I'm not Zod but I believe GBA emu can be fullspeed. At what clockrate I don't know!

Little question : I often heard of DS or GBA running SNES games... Since theyre both ARM-based, is it possible to take a look at how they perform well with so weak processor?

The PocketSNES emulator is based off that code.
 
Last edited by a moderator:
I was going to work on this, but a not very working GP2X and no real time has proved prohibitive :( Although it'd probably be good if zodttd talked to me sooner so I could tell him to do something totally different than what he tried. I'll try to steer him in the right direction ;P

If you're reading this now, do NOT do a dynamic register allocation scheme, unless you understand when to spill it'll be totally broken (and it's probably not worth it anyway). You can use a static allocation instead. Of the 15 registers ARM gives you, you need to reserve:

- base pointer
- cycle counter
- 4-5 temporaries, the memory stubs require the biggest footprint, but you might not need all of them in the end. Can probably work this to 4.
- flags register
- link register (for calling stubs), maybe can use this for a temporary

That leaves you 6-7 remaining. All things considered, if the performance of the interpreter isn't THAT bad then things will probably still be okay with this.
 
Hi everyone,

Progress is being made. I have some time to work on it today and I'll see what we land up with. :)

Thanks for the help Exophase, without you we wouldn't have the chance to see this project. :) ...I'm currently reserving the:
- base pointer (r4)
- cycle counter (r12, hope this is safe now that I think of it),
- your define for reg_s0 (r5)
- the link register for calling conventions
The temporary regs are not reserved (I added a temp reg for immediate conversions). They're tossed even on calls. I should probably push/pop them as well on the calls. The memory stubs are treated as if they're a sub routine. They preserve R4,R5,R12 (and LR when needed) within the stub, but after doing the bx lr and back to recompiled code, the regs for the recompiled code are popped. Only variation to this is the cycle counter where it may be changed within the memory stubs, and in that case r12 isn't pushed/popped.
I'm a bit confused as to what the primary purpose of reg_s0 is in this case. It seems to have dual purposes.

Either way, I only would have at max 4 reserved registers if I use the push/pop method described above. That means I can allocate:
- r4 to r8 (might be able to squeeze in r9 and r10)
- change reserved regs to the higher end of r9,r10,r11,r12...I can probably take out the cycle counter and use reg[] memory but not worth it most likely. I can also probably reduce this by one reg by not reserving a temporary reg.

Question, what to do about a0 to a3? Nothing really uses r3 and when I push/pop I can secure that reg as static alloc right? r2 might be tricky, and a0 and a1 would be out of question right?

msg me when you have a chance. ;)
 
I'm in awe. Best of luck to both of you in getting this figured out. Can't wait for Dynarecced GBA :). Should be amazing as and when!
 
Yeah, Thanks Exophase and Zodttd.

You guys are amazing coders. Hope things work out.
 
First of all I just want to thank Zodttd. And I also wanted to note that on the last topic about gpsp I was obsessed and hardly ever left my computer. Well anyway, I just literally got back from Kenya, Africa. I was visiting some friends of the family and holy shit I have been playing Golden Sun OC at 270 and getting far. All of a sudden after 2 weeks of showing off the 2x in Africa I come home and Zodttd is close to making this thing full speed. I fucking love this guy :D .
 
Ya know... I'm a coder with a bit of knowledge of assembly and computer architecture and I can't imagine what the hell Zodttd is doing. (Well, besides the very generic idea.) It's really humbling.
So, kudos from a new guy here.
 
Back
Top