New LLE RSP Plugin (accurate, fast but untested?)

[HatCat]

Originally Posted by RPGMaster

I did some reading and it seems like there wouldn't be too much of a performance gain from statically compiling. I just thought it would be awesome to convert roms into native code. I now see why not many people are interested in doing this kind of stuff. Time for me to hit the books .

Legacy shows that there is a huge performance gain over the virtual overhead with using an emulator instead, but depending on the type of translator you do, the ends may not justify the means. Most people don't want to go through all the work is all, I imagine.

Originally Posted by MarathonMan

TIL Corn doesn't write executables in PE format.

Exactly, so it's not a translator in the same sense that a Win32 porter is.

Based on your level of induction, I could write an interpreter that translates the MIPS operations individually, one-by-one, into several x86 instructions each, and it would STILL be a translator that "statically `recompiles`" the ROM into a Win32 executable using interpreter theory, not code block caching and re-compiler theory. It does NOT have to use dynamic or any recompiler emulation theory, because it is not an emulator.

[RPGMaster]

Originally Posted by MarathonMan

All it really buys you is the ability to do really expensive analysis; something you cannot afford to do at runtime. However, as the author of the article stated, you have to shelf a lot of the optimizations in favor of accuracy much of the time.

Lol that's something interesting that I didn't think about. I guess it is somewhat useful then.

Originally Posted by HatCat

Legacy shows that there is a huge performance gain over the virtual overhead with using an emulator instead, but depending on the type of translator you do, the ends may not justify the means. Most people don't want to go through all the work is all, I imagine.

I agree that the ends may not justify the means.


I'm curious though. Lets say you were successfully able to statically recompile a n64 rom. If I wanted to change a game, would it be useful to convert it to C code using IDA, or would I be better off just sticking to assembly?

[HatCat]

De-compiling it into C code would without question be better.

Because, think about it. If you try to translate the raw assembly commands from one language to another (in a direct fashion similar to the basic interpreter algorithm, void of re-compiler emulation theory), you would have a much easier time doing it, but it would be nowhere near as optimized as if it was produced by a static re-compiler.

Even then, even if you DID translate it to some EXE file using static recompiler theory, you really can't compete against the years of work put into optimizing compilers like GCC or the stuff in Microsoft's Visual Studio packages. There's no way you can compete against simply having the C source code of the program, even if it's too ugly and fixated due to the nature of how you managed to decompile the ROM into it.

[RPGMaster]

I guess I need to practice C more then. I've tried decompiling my own programs and I've never been able to successfully compile the generated C code from IDA. I guess it probably has to do with library calls. I'll try again today though.

Another issue I have with decompiling is how messy the code looks. It's so bad to read lol.

[HatCat]

Well I never was able to get IDA to work. IIRC it's not free, so I'd have to pay for it, idk.

Just de-compiling any machine code into C is one thing, but it's entirely another to produce highly portable C code as a result. You might have to change several things. Honestly, call me unambitious, but I've never once compiled a N64 executable from C source code before (like what ability the common N64 dev libs provide you). Maybe if you can get any old demo compiling from C source, you'll have a better understanding of the way the operating system works and how you'd need to tend to the resulting C.

Many times, C looks much worse and harder to read than assembly, while the exact opposite is also true. It's a balance between the fundamental design of any logical computer architecture (portability) versus the fixations of natural or mathematical algorithms tied down to the constraint of modern computer science. If ever there were a non-binary-based computer architecture, C wouldn't be quite so useful, but it'd still be multitudinously more useful than an assembly language. (On top of that, pretty much any specific asm language has something shitty or at least ugly, if not under-performing, about it. Don't forget that language doesn't replace the merits of algorithm.)

[RPGMaster]

I'd imagine it's especially difficult to port optimized machine code into C. I know that when I tried decompiling a random program I made in x86, it couldn't convert certain parts so it had some inline assembly.

I'm pretty sure IDA has a free trial, but I could be mistaken.

[HatCat]

True...it would be hard, next to impossible, to de-compile a byte-swap instruction to the C language, in a way that once compiled in a C compiler, would still produce a byte-swap instruction OR, has the memory endianness adjusted all throughout the entire block of code so that no byte-swap would be needed in the first place (like by means of aliased data writes, accomplishing the transactions of multiple bytes simultaneously).

Easy to do period, just hard to do in a way that the C code isn't slower than the assembly code, for those rare operations. I personally have never needed to use a bswap instruction in any of my C projects; somehow I've always evaded the need for it. Closest thing I've done to bswap is SSE shuffling.

[Bighead]

After skimming through about 50 pages of this thread, I gotta say amazing work on this Icono. I don't know how I overlooked this thread/plugin for so long. A big part of it is I haven't been very active in emulation forums in a long time, nor have I played many N64 games in the past years. I remember when you got started on this in the beginning of 2012, if I remember correctly, and it's certainly come a long way. I immediately tested it in a few games with all kinds of plugins and emulators and it works flawlessly in every single game I tested, no matter if its HLE or LLE plugins. This basically replaces every single RSP plugin currently in existence.

[HatCat]

Originally Posted by Bighead

After skimming through about 50 pages of this thread, I gotta say amazing work on this Icono. I don't know how I overlooked this thread/plugin for so long. A big part of it is I haven't been very active in emulation forums in a long time, nor have I played many N64 games in the past years. I remember when you got started on this in the beginning of 2012, if I remember correctly, and it's certainly come a long way. I immediately tested it in a few games with all kinds of plugins and emulators and it works flawlessly in every single game I tested, no matter if its HLE or LLE plugins. This basically replaces every single RSP plugin currently in existence.

Well I'm glad you think so.
My objective was to make it complete after all. Thanks to some official information, I was even able to help zilmar fix a few surviving unknowns about the RSP on his end. Yeah, when I sent you that e-mail in 2012 I was still developing my skills a bit.

It's almost as fast as--if not even faster than (or, sometimes slower, like if you have an AMD K8 with no SSSE3 support like I do)--Jabo's MMX recompiler code, the standard RSP recompiler plugin everybody's been using for Project64. Of course, the fact that I've pretty much immunized my code from breaking any games as far as I could tell tends to break over that tie somewhat--a recompiler is useless if an interpreter can succeed it in speed.

Additionally for those who don't know, MarathonMan needed to use my source base to finally put an end to lots of confusing RSP bugs he was having, so the CEN64's RSP emulation will essentially be a cycle-accurate variation of mine.

But with the RSP out of the way, the more challenging problem of the RDP is a much more complex thing to tackle for me it seems....

[uyjulian]

I wonder if you are going to move on to something else emulation-related or just move on to something else entirely?