Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Significant progress made on Xbox 360 recompilation

readonlymemo.com

Post reply on HN
Print view View original

31–37 of 37 posts

Re: Significant progress made on Xbox 360 recompilation

#31

Post by charcircuit »

CJefferson wrote: post #22
rendaw wrote: post #17

Years ago I was searching for why emulators don't recompile to native bytecode and it seemed like the consensus at the time was that JIT etc was faster. I can't find it now, but IIRC I remember replies from maintainers saying it was a bad idea. What changed since then, since this seems to be a trend? Is this more for more modern systems that have more static code?

Static code. Also, very fine details of the machine because less important. When emulating a NES (for example), you really have to emulate every register, how registers change, and also weird effects like instructions that take longer to read or write values, as games rely on that stuff. Once you have modern systems where much of the code was originally C, it becomes less important to ensure every register has exactl…

You really don't. Most of the time the code will be doing normal things. So you can have other code that also does the same thing.

>and also weird effects like instructions that take longer to read or write values

The percentage of a code in the ROM that depends on such things is a small percent.

Re: Significant progress made on Xbox 360 recompilation

#32

Post by tetrisgm »

wesfenlon wrote: post #16

Hey, that's my newsletter -- thanks for sharing! :D Some exciting stuff has already happened in the week since I wrote the interview. Here's Viva Pinata: Trouble in Paradise: https://www.youtube.com/watch?v=Kih42KlocII

btw any way to reach out to you (twitter, discord?). big fan of your blog. I'd say on par with Time Extension!

Re: Significant progress made on Xbox 360 recompilation

#33

Post by CJefferson »

charcircuit wrote: post #31
CJefferson wrote: post #22

Earlier quoted context omitted.

Static code. Also, very fine details of the machine because less important. When emulating a NES (for example), you really have to emulate every register, how registers change, and also weird effects like instructions that take longer to read or write values, as games rely on that stuff. Once you have modern systems where much of the code was originally C, it becomes less important to ensure every register has exactl…

You really don't. Most of the time the code will be doing normal things. So you can have other code that also does the same thing. >and also weird effects like instructions that take longer to read or write values The percentage of a code in the ROM that depends on such things is a small percent.

The problem with NES emulation (having written a fairly bad one) is it can be hard to predict when you need to be careful, particularly in the presence of self-modifying code and interrupts. If it was easy to figure out, emulators wouldn't have to keep such careful track of this stuff either.

Re: Significant progress made on Xbox 360 recompilation

#34

Post by xnx »

giancarlostoro wrote: post #4

The blog post reminds me of similar efforts with Shockwave. There's people building decompilers, and runtimes, and if you join enough Discords, you will notice the people in them are cross-contaminating between communities if you will, they share insights with one another, in their efforts towards specific goals. They're hyper focused on making one game or another come back. There's Habbo Hotel, and Coke Studios, as…

> cross-contaminating between communities if you will

The positive term for this is cross-polinating

Re: Significant progress made on Xbox 360 recompilation

#35

Post by pezezin »

zxspectrum1982 wrote: post #30

I wonder whether this "recompilation" technology could be used to run Windows software on Linux, as an alternative/complementary technique to Wine. Back in the day (year 2000, until 10-15 years ago) we had Project Odin to dynamically translate Windows software to run on OS/2: https://github.com/netlabsorg/odin32

Windows and Linux run on the same x86 CPU architecture, you don't need to recompile anything. What WINE does is to translate/replace system calls and libraries.

Re: Significant progress made on Xbox 360 recompilation

#36

Post by krackers »

bri3d wrote: post #14
kaladin-jasnah wrote: post #7

Earlier quoted context omitted.

Seeing this [1], I thought it was something related to taking assembly instructions in the original code, emitting C statements that match the instruction, and then compiling that C code. [1] https://github.com/N64Recomp/N64Recomp

Your idea is much more accurate; see my sibling comment. It's basically using C or C++ as an intermediate representation for machine code, rather than trying to recreate the game's higher-order logic/structure or source code.

This vaguely reminds me of futamura projections.

Normally with futamura's first projection the input is source code, and you partial-evaluate that source against an interpreter for that source, resulting in a "compiled" binary that has the logic of the source inlined into the interpreter (and hopefully optimized). This is similar to what Truffle does I believe, where you have an interpreter (written in java) and then during runtime Truffle "JIT" optimizes the interpreted program's AST against the interpreter's logic. All of this can be considered a specialization of the JVM running an interpreter interpreting your program.

In this case with "recompilation" you have a binary made to run on certain hardware. You then take an emulator of the hardware (registers, PC, etc.) and then "partial evaluate" the binary against the hardware emulator, producing a new program that contains a software emulation of just that specific binary.

So while you're still conceptually emulating the underlying hardware, you both avoid the instruction dispatch overhead at runtime (it's statically compiled in) and also benefit from the optimization passes of modern compilers.

Re: Significant progress made on Xbox 360 recompilation

#37

Post by zxspectrum1982 »

pezezin wrote: post #35
zxspectrum1982 wrote: post #30

I wonder whether this "recompilation" technology could be used to run Windows software on Linux, as an alternative/complementary technique to Wine. Back in the day (year 2000, until 10-15 years ago) we had Project Odin to dynamically translate Windows software to run on OS/2: https://github.com/netlabsorg/odin32

Windows and Linux run on the same x86 CPU architecture, you don't need to recompile anything. What WINE does is to translate/replace system calls and libraries.

I know how Wine works, thank you. I've used winelib in the past to port Windows software (that I had the source code of) to Linux myself.

My point is the way wine works today is: WinAPI --> winelib --> Linux --> x86

I. e. winelib is reimplementing WineAPI on top of Linux.

What if we could just decompile those Windows functions and recompile them on Linux, or even x86, directly?

The workaround all of these console recompilation projects use is you must have the original game in order to have the binaries (the ones you theoretically decompile and recompile, but actually you take pre-decompiled-recompiled ones by someone else) and assets (graphics, sounds, etc). For Windows applications on Linux, we could do the same: bring your own Windows, then we can decompile and recompile.

Post reply on HN