|
Emulator: Interpreter vs. Compiler?
#248773 - 03/14/11 01:17 AM
|
|
|
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: safreen]
#248775 - 03/14/11 01:35 AM
|
|
|
Do you know what a DRC is?
|
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: Matty_]
#248776 - 03/14/11 02:03 AM
|
|
|
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: safreen]
#248791 - 03/14/11 04:50 AM
|
|
|
I think the nearest is CXBX emulator, it translates an XBOX .BIN exacutable into a .EXE one. Makes sense, because an XBOX it's basically a PC with custom graphic card and inputs.
If I'm not wrong DRC only compiles some instructions, as many as its dictionary lets it compile, so emulation gains performance. What he describes is a translator, a program which converts say Z80 instructions into a binary working exclusively under a specific platform (i.e. x86 instructions under Windows). That could have been feasible on the DOS days, but today with assembly language being technically obsolete unless you program micro controllers, it's unmaintainable and useless.
|
|
|
|
It's called "static recompiler"
[Re: BIOS-D]
#248803 - 03/14/11 08:12 AM
|
|
|
|
|
|
Re: It's called "static recompiler"
[Re: safreen]
#248808 - 03/14/11 08:50 AM
|
|
|
Here is one interesting way to do a static recompiler:
http://www.gtoal.com/sbt/
There are two big problems with static recompilation: 1) dynamic code (self-modifying programs as well as programs that copy or load code into RAM), and 2) timing. For some systems, timing and synchronization might not be important, but for many old consoles and arcades, they are. Dynamically loaded code means you may have to lug the translator itself around in the binaries you produce because it is virtually impossible to detect this kind of stuff at compile-time.
|
Bart
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: BIOS-D]
#248823 - 03/14/11 03:17 PM
|
|
|
MAME's DRC is caching, meaning the translation pass to x86/x64 binary code runs once per instance of emulated (MIPS/PowerPC/SH-2) code and you therefore get the run-time performance of a static recompiler without all of the problems. (And since it's dynamic, it can handle the self-modifying code that occurs somewhat frequently in e.g. ST-V games programmed by Success).
Also, it handles the complete instruction set of each emulated processor. The "dictionary" is unabridged.
And of course none of this is a new idea - the first non-commercial emulator with a DRC was PSEmuPro back in like 1998.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: safreen]
#248840 - 03/14/11 08:03 PM
|
|
|
To clarify: MAME can already do something very much like this for some processors. The difference is we allow the execution flow of the code itself to point out what is code and what is data in ROMs, something which historically has been a major problem with static recompilation.
Because most CPUs don't have fixed-size instructions you can end up desynced with the real code by trying to just blindly compile (as in static recompilers), and it gets worse on CPUs where the same binary opcode has different meanings depending on the CPU's live state. I do know one successful use of something like static recompilation - some early GBA games used a special cross assembler which took 65816 opcodes as input and produced ARM instructions as output. But again, since you're working off the source rather than a bare binary, you avoid the problem of "accidentally" compiling data.
|
|
|
|
Re: It's called "static recompiler"
[Re: Bart T.]
#248887 - 03/15/11 06:32 AM
|
|
|
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: R. Belmont]
#248889 - 03/15/11 07:01 AM
|
|
|
|
|
|
Re: It's called "static recompiler"
[Re: safreen]
#248891 - 03/15/11 07:15 AM
|
|
|
This was done a LOT back in the day when memory and storage were very expensive. I know it was used often in PC video driver code and in DOS games.
I can't say for sure which, if any arcade games did this, but since the game designers were also limited by expensive memory chips, I'm sure they probably did it too.
|
GroovyMAME support forum on BYOAC
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: R. Belmont]
#248892 - 03/15/11 07:24 AM
|
|
|
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: safreen]
#248897 - 03/15/11 09:50 AM
|
|
|
> > MAME's DRC is caching, meaning the translation pass to x86/x64 binary code runs
> once
> > per instance of emulated (MIPS/PowerPC/SH-2) code and you therefore get the
> run-time
> > performance of a static recompiler without all of the problems. (And since it's
> > dynamic, it can handle the self-modifying code that occurs somewhat frequently in
> > e.g. ST-V games programmed by Success).
>
>
> That's great, you already can handle the most difficult part - the stuff that is
> 'hard to know' at compile time, and as such those platforms seem already suitable for
> a nice hybrid optimisation, or perhaps something like Java virtual machine does with
> its 'intermediate byte-code'.
>
> Possibly most of the game ROMs could be pre-processed to some intermediate
> 'byte-code', and we could leave 'uncertain branching' and 'self-modifying code' parts
> to be done by via DRC... but then, after we play the game long enough we would
> eventually have the WHOLE game traversed and statically recompiled somewhere in the
> computer memory, and then all we need is to dump it all to a file, right?
Why bother, the ROMs are already in a form of "byte code" 
|
Bart
|
|
|
Re: It's called "static recompiler"
[Re: safreen]
#248898 - 03/15/11 10:09 AM
|
|
|
> > Here is one interesting way to do a static recompiler:
> > http://www.gtoal.com/sbt/
>
>
> That's perfect, thank you.
>
>
> 1.) dynamic code (self-modifying programs)
>
> I would be surprised if any game boards use anything like this, except maybe for
> protection. Can you please be more specific?
Old games do it more than you might think for all sorts of weird reasons.
>
>
> 2.) programs that copy or load code into RAM
>
> You mean if the code is compressed or otherwise not part of the code segment but
> "hidden" somewhere in the data segment and indistinguishable from the rest of the
> data, or what R. Belmont calls - problem of "accidentally" compiling data, or is
> there more and something else?
There is no "code segment". You can think of ROMs as being system-level code (like an OS or BIOS). Often times, they copy portions of the game program around to different parts of RAM, and it's not necessarily because the code is compressed. ROM is slower than RAM.
Even if you could identify code in ROM (RB touched upon the syncing problem for processors with variable-length instructions), you don't actually know where it's going to be executed from, so you can't translate it. And we haven't even touched upon code stored on hard drives or optical discs, which also has to be loaded into RAM.
> All in all, MAME seem to be the worst place to start, I should probably find the
> simplest Z80 emulator for something like ZX Spectrum or Amstrad CPC, and that would
> also already have almost compatible assembler with x86 in case that turns out to be
> important or helpful. But again, my expertise has little to do with emulators, so I
> would like a little bit more information or point to some better place where to
> start, then I could do the rest myself, I think.
>
I think it would be harder for these old systems, except for very simple programs.
> "fan-made remake". The point I am trying to make is that these 'remakes' are actually
> legal unless being sold, since they do not violate game license or ROMs copyright,
> but rather the trademark associated with the use of characters, names and logos, or
> so it would seem. What do you think?
It would not be legal. Not only is it a derived work, being a simple transformation of the original code, it would also contain copyrighted data.
|
Bart
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: safreen]
#248899 - 03/15/11 10:18 AM
|
|
|
> How hard can it be? :-)
did you already send the patch with the simple changes?
|
|
|
| AWJ |
|
|
|
|
|
|
|
Reged: 03/08/05
|
|
Posts: 936
|
|
Loc: Ottawa, Ontario
|
|
|
|
Send PM
|
|
|
Re: It's called "static recompiler"
[Re: krick]
#248900 - 03/15/11 12:15 PM
|
|
|
> I can't say for sure which, if any arcade games did this, but since the game
> designers were also limited by expensive memory chips, I'm sure they probably did it
> too.
I think a few CPS1 and CPS2 games use self-modifying code.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: It's called "static recompiler"
[Re: krick]
#248903 - 03/15/11 02:55 PM
|
|
|
> > 1.) dynamic code (self-modifying programs)
> >
> > I would be surprised if any game boards use anything like this, except maybe for
> > protection. Can you please be more specific?
>
>
> This was done a LOT back in the day when memory and storage were very expensive. I
> know it was used often in PC video driver code and in DOS games.
>
> I can't say for sure which, if any arcade games did this, but since the game
> designers were also limited by expensive memory chips, I'm sure they probably did it
> too.
I've seen self-modifying code in arcade boards from 1978 through PSX-based stuff in the early 2000s. And it's not for protection.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: It's called "static recompiler"
[Re: safreen]
#248904 - 03/15/11 02:59 PM
|
|
|
> You mean if the code is compressed or otherwise not part of the code segment but
> "hidden" somewhere in the data segment and indistinguishable from the rest of the
> data, or what R. Belmont calls - problem of "accidentally" compiling data, or is
> there more and something else?
Arcade ROMs are normally raw binary data - there is no ELF or EXE structure involved, and therefore there is no "code segment" or "data segment", there is only bytes.
Worse, most 32-bit games copy code from ROM to RAM before executing it, so multiple ROM chunks execute from the same RAM space over the lifetime of the game. A DRC can handle that easily enough (just flush the old code); a static recompiler would be in serious trouble. There's a reason the static-recompiler N64 emulator only ran like 3 games while DRC ones like Project64 run everything.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: safreen]
#248906 - 03/15/11 03:02 PM
|
|
|
> I mean MAME already does everything, so this should only be a matter of obtaining all
> the corresponding chunks of code and arranging them in appropriate sequence while
> preserving relations between memory locations, branching and jumps, as well as
> timing.
Right, and all of those are the hard part. Arcade ROMs are raw binaries; there is no segment information to distinguish code from data (and even if there were, SH-2/SH-4 binaries normally stuff constant data in the code segment due to that processor not having immediate loads larger than 8 bits).
A lot of people think they're smarter than MAMEdev and burst on here to announce something they're sure we haven't thought of. Reality check: we've thought of it 
|
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: Bart T.]
#248917 - 03/15/11 04:23 PM
|
|
|
|
|
|
Re: It's called "static recompiler"
[Re: Bart T.]
#248918 - 03/15/11 04:34 PM
|
|
|
|
|
|
Re: It's called "static recompiler"
[Re: safreen]
#248923 - 03/15/11 05:00 PM
|
|
|
You seem you pretend to know it all, yet you to don't know anything. Not only MAME would need to translate opcodes to the architecture MAME is running on for every emulated processor, they would need to build their own compiler for every platform.
Do you get the idea?, trying to emulate anything and also working on specific compilers (and decompilers) so your static compiled code can run on Mac, Linux and Windows? It's unmaintainable (let alone portable). Why bother using compilers like GCC when it's easier for everyone to make their own? (sarcasm).
And seriously, are you involving Java into this? A platform which compiles source code (different to opcodes which need to be decompiled first) into Java bytecodes generated by themselves? Of course it's easy for them, they know their own code. That doesn't stop the fact they have to make a compiler and an interpreter for every platform Java is working on.
MAME cares for emulation (but mostly hardware documentation) which is a huge task alone.
You don't happen to know "abaraba", do you?
|
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: etabeta]
#248926 - 03/15/11 05:41 PM
|
|
|
|
|
|
Re: It's called "static recompiler"
[Re: R. Belmont]
#248927 - 03/15/11 05:47 PM
|
|
|
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: R. Belmont]
#248930 - 03/15/11 06:14 PM
|
|
|
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: safreen]
#248946 - 03/15/11 09:03 PM
|
|
|
I guess what you mean is an intermediate representation so you can decouple the front end and back end. MAME's DRC does this. It's certainly possible.
|
Bart
|
|
|
Re: It's called "static recompiler"
[Re: safreen]
#248947 - 03/15/11 09:08 PM
|
|
|
Sure, you could generate a list of instructions and the addresses they appear at at run-time, which is basically how Graham's method works but you've got to make sure that you execute all possible code. The easy way to solve this is to lug around the original ROM with you and interpret anything you missed. A much, much more difficult alternative is to do something like FX!32 (the old X86->Alpha translator for Windows NT), which caches translated blocks on disk and updates this each time the program is run. But again, the problem here is that you have to retain the ROM.
In all cases, you will have to retain the ROM code for on-the-fly translation.
|
Bart
|
|
|
Re: It's called "static recompiler"
[Re: safreen]
#248949 - 03/15/11 09:10 PM
|
|
|
It's not a problem for DRCs, as RB mentioned. DRCs can handle all of these problems because when a RAM region corresponding to an existing translated block of code is modified, the translation is flushed (the block is marked 'untranslated', so to speak, and the next time the processor hits that point, it will be translated anew).
|
Bart
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: safreen]
#248951 - 03/15/11 09:16 PM
|
|
|
Intermediate code would be generated as a result of the procedure Graham describes. You cannot statically preprocess a ROM for all the reasons we've discussed: you cannot distinguish code and data.
|
Bart
|
|
| drewcifer |
|
One bad Mutha-(shut yo' mouth!)
|
|
|
|
|
Reged: 07/01/04
|
|
Posts: 428
|
|
Loc: Sweden
|
|
|
|
Send PM
|
|
|
Re: It's called "static recompiler"
[Re: Bart T.]
#248952 - 03/15/11 09:24 PM
|
|
|
> Sure, you could generate a list of instructions and the addresses they appear at at
> run-time, which is basically how Graham's method works but you've got to make sure
> that you execute all possible code. The easy way to solve this is to lug around the
> original ROM with you and interpret anything you missed. A much, much more difficult
> alternative is to do something like FX!32 (the old X86->Alpha translator for Windows
> NT), which caches translated blocks on disk and updates this each time the program is
> run. But again, the problem here is that you have to retain the ROM.
>
> In all cases, you will have to retain the ROM code for on-the-fly translation.
You just have to play a game, doing absolutely everything possible to do in the game (hardware failure interrupts included), making sure you hit every bit of code, and you're golden .
Andrew
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: safreen]
#248955 - 03/15/11 09:37 PM
|
|
|
> Ok, can you be more specific why and how would this algorithm fail: - "Our algorithm
> is simply that the disassembler outputs (prints to file) code for each instruction
> instead of executing it."
Because if your ROM binary consists of something along these lines:
800: LDX #00
802: LDA #$C1
804: JSR $FDED
807: JMP $0017
80A: asc "Hello World!"
817: (code continues)
you will almost certainly lose "code sync" during the string at 0xA and end up disassembling incorrectly when you get back to code at 817.
> I find your response, and that of BIOS-D, quite odd, you two reacted as if I
> criticized MAME, which I did not. I need you for this, I can not possibly do it by
> myself. I would not be asking you questions if I did not think you can help me find
> the answers. Is that ok, are we cool?
Well, your implication was that you'd discovered some amazing way to make games emulate faster that MAMEdev hadn't. Meanwhile we do use DRC, which gives equivalent run-time performance to static recompilation while avoiding the code/data problem entirely. So I'm still fuzzy on why this is even a thing.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: It's called "static recompiler"
[Re: safreen]
#248956 - 03/15/11 09:41 PM
|
|
|
> It's not "derived" work in usual sense, it's "reverse-engineered" and this wording
> can be important, but I argue it would be a "remake" with its own copyright just like
> if you get a camera and film Star Wars remake with your friends as actors, that's
> completely different than if you took camera and film the actual movie in theater.
Sure it's derived. If I translate "The Shining" into Spanish, it's still Stephen King's copyrighted work. That's all a static recompiler does: translate code into another language.
|
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: R. Belmont]
#248985 - 03/16/11 04:14 AM
|
|
|
IIRC, Graham's algorithm runs an interpreter through the code and then outputs what it encounters. That's why he doesn't have a problem with code syncing.
|
|
|
|
|
[ATTACHED IMAGE]
|
|
|
|
Re: It's called "static recompiler"
[Re: Bart T.]
#248994 - 03/16/11 05:20 AM
|
|
|
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: R. Belmont]
#248995 - 03/16/11 05:37 AM
|
|
|
|
|
|
Re: It's called "static recompiler"
[Re: R. Belmont]
#248996 - 03/16/11 05:51 AM
|
|
|
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: R. Belmont]
#248997 - 03/16/11 05:56 AM
|
|
|
|
|
|
Re: It's called "static recompiler"
[Re: safreen]
#249003 - 03/16/11 07:48 AM
|
|
|
It's just as illegal as a ROM.
|
|
|
|
Re: It's called "static recompiler"
[Re: safreen]
#249004 - 03/16/11 07:51 AM
|
|
|
> > Sure, you could generate a list of instructions and the addresses they appear at at
> > run-time, which is basically how Graham's method works but you've got to make sure
> > that you execute all possible code.
>
>
> So, we arrived to the point where we can realize the ONLY problem is actually how to
> get this thing to traverse all possible code, and what we are talking about here
> really is DRC that instead of caching the code in memory outputs it to a file, and
> what would we normally call "runtime" is simply just a process of static
> recompilation taking some time.
>
> How does that sound, makes sense?
I don't know if Graham's method can handle self-modifying code, or code that is overwritten with new code. Remember, a single RAM location will contain different code at different times. Even if you "detect" all the possibilities, how would you distinguish between them if all you track is the address and opcode that appears there?
|
|
|
|
Re: It's called "static recompiler"
[Re: Bart T.]
#249009 - 03/16/11 09:23 AM
|
|
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: Bart T.]
#249028 - 03/16/11 05:58 PM
|
|
|
> IIRC, Graham's algorithm runs an interpreter through the code and then outputs what
> it encounters. That's why he doesn't have a problem with code syncing.
Right, if you can guarantee 100% coverage of the code. That's difficult even on simple games.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: It's called "static recompiler"
[Re: safreen]
#249029 - 03/16/11 06:08 PM
|
|
|
> I'm afraid that's too vague for me to grasp the problem you are talking about. I'd
> say - it depends, but we need to be more specific in order to avoid assumptions. The
> only two kinds of "self-modifying code" I can think of are these two:
>
> a.) compressed code
>
> b.) encrypted code
Those are both correct. However, there's a third case: all of the systems that currently use DRCs run code almost exclusively from RAM, and they all use overlays to do so. And a fourth case: code that actively constructs other code based on the game state and then runs it. And a fifth where some code is copied into RAM by an external protection device.
All of these combine to mean the same RAM location could have dozens or hundreds of unique pieces of code occupying it over the lifespan of a game.
So to achive static recompilation, you need:
1) to guarantee 100% coverage of the game's code on a single interpreter run
2) some way to track all of the different code configurations that occur in RAM during that run, which can number in the hundreds on ST-V games, let alone systems with more RAM like Naomi
And after that, all you can hope for is the exact same performance improvement that a DRC already yields without having to deal with any of those problems. Therefore, there is zero reason for MAMEdev to pursue this.
|
|
|
Stiletto |
|
They're always after me Lucky ROMS!
|
|
|
|
|
|
Reged: 03/07/04
|
|
Posts: 6472
|
|
|
|
|
|
Send PM
|
|
|
Re: It's called "static recompiler"
[Re: R. Belmont]
#249031 - 03/16/11 06:56 PM
|
|
|
> And after that, all you can hope for is the exact same performance improvement that a
> DRC already yields without having to deal with any of those problems. Therefore,
> there is zero reason for MAMEdev to pursue this.
This "safreen" dude is quite obviously not worried about performance, just using that as a way to start discussion. He's probably looking into whether he can create a static recompilation of some popular game, target (my guess) a handheld or iPad or console or something, and advertise it (even non-commercially) as a fan-made remake. (Oh, and manipulate MAMEDEV into doing the work for him, as a bonus.)
I wonder how many times we have to say "it's illegal - a violation of copyright" before he gets it... 
Even forgetting the legality of translating code via static recompilation from one language to another, there's still tons of copyrighted media (graphics, music, sound effects) in the final product.
- Stiletto
|
|
|
|
Re: It's called "static recompiler"
[Re: Stiletto]
#249032 - 03/16/11 07:04 PM
|
|
|
> This "safreen" dude is quite obviously not worried about performance, just using that
> as a way to start discussion. He's probably looking into whether he can create a
> static recompilation of some popular game, target (my guess) a handheld or iPad or
> console or something, and advertise it (even non-commercially) as a fan-made remake.
> (Oh, and manipulate MAMEDEV into doing the work for him, as a bonus.)
Which strongs my belief he's in reality "abaraba" (a.k.a multidisciplinary guy who believes know more than anyone else). Maybe R.Belmont should fake and prove him right (so he could then change the topic in another direction) to verify.
|
|
|
| drewcifer |
|
One bad Mutha-(shut yo' mouth!)
|
|
|
|
|
|
Reged: 07/01/04
|
|
Posts: 428
|
|
Loc: Sweden
|
|
|
|
Send PM
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: safreen]
#249036 - 03/16/11 07:25 PM
|
|
|
> That's not how the algorithm works, it does not step over the code blindly like that,
> but just like MAME will not lose that string and can emulate it all properly, so can
> that algorithm too, it is pretty much the same thing as DRC with only difference that
> cache is saved to a file and what would we normally call "runtime" is simply just a
> process of static recompilation taking some time. Makes sense?
Something about the post above tickled a memory of mine. See if you can spot the similarity (hint: it's at the end of the post in both cases).
http://forum.arcadecontrols.com/index.ph...3590#msg1153590
Andrew
|
|
|
|
Re: It's called "static recompiler"
[Re: Stiletto]
#249039 - 03/16/11 07:52 PM
|
|
|
Here I figured he was just looking for dexterMAMETM. 
Kevin Eshbach
|
|
|
| Stiletto |
|
They're always after me Lucky ROMS!
|
|
|
|
|
|
Reged: 03/07/04
|
|
Posts: 6472
|
|
|
|
|
|
Send PM
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: drewcifer]
#249040 - 03/16/11 07:53 PM
|
|
|
> > That's not how the algorithm works, it does not step over the code blindly like
> that,
> > but just like MAME will not lose that string and can emulate it all properly, so
> can
> > that algorithm too, it is pretty much the same thing as DRC with only difference
> that
> > cache is saved to a file and what would we normally call "runtime" is simply just a
> > process of static recompilation taking some time. Makes sense?
>
> Something about the post above tickled a memory of mine. See if you can spot the
> similarity (hint: it's at the end of the post in both cases).
>
> http://forum.arcadecontrols.com/index.ph...3590#msg1153590
Well, that adds up.
- Stiletto
|
|
|
|
Re: It's called "static recompiler"
[Re: R. Belmont]
#249045 - 03/16/11 09:00 PM
|
|
|
|
|
|
Re: It's called "static recompiler"
[Re: BIOS-D]
#249049 - 03/16/11 09:31 PM
|
|
|
Come on, guys, give him the benefit of the doubt. He is not claiming to be an expert and readily acknowledges his lack of familiarity with emulation. He's probably just excited and curious. Nothing wrong with that. We've all been there before.
I would advise him to sit down and try writing an emulator. It'll be an edifying experience and a lot of the problems we've been discussing here will finally have a chance to crystallize.
|
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: R. Belmont]
#249050 - 03/16/11 09:34 PM
|
|
|
Right.
I know Graham's method did work quite well for some games. Specifically, I think he developed this for Tailgunner (?). It's been a while since I've read that page, but I believe it is likely he is doing something a bit more sophisticated than just waiting for the interpreter to hit each instruction. A simple modification would be to continue fetching until an unrecognized instruction is hit. In this way, most of the unexecuted code paths would be covered, even if the interpreter didn't ever get there.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: It's called "static recompiler"
[Re: Bart T.]
#249052 - 03/16/11 09:40 PM
|
|
|
He's the troll abaraba. We've now confirmed it. Mods should be along shortly
|
|
|
|
Re: It's called "static recompiler"
[Re: R. Belmont]
#249054 - 03/16/11 10:48 PM
|
|
|
> He's the troll abaraba. We've now confirmed it. Mods should be along shortly
Taken care of.
|
|
|
|
Re: It's called "static recompiler"
[Re: twisty]
#249055 - 03/17/11 12:03 AM
|
|
|
Hah, well, in that case, fool me once...
|
|
|
|
Took ya all long enough....
[Re: twisty]
#249066 - 03/17/11 04:18 AM
|
|
|
Man, I was thinking that after about his fifth response. Especially because he wasn't saying, or even hinting at, what his intended result was. I was about to post asking, 'What the fuck do you want to do with this??'....but I held off because I had the feeling it would out in later posts. And it did.
What's fascinating is, as I always stop at the main page first and look at the then-current mamedev quote, I saw this RB quote today, and was wondering whether a multiple core machine could run your OS, etc, on one; then have another core perform machine language game operation...but...then it'd have to be translated before video output, huh? Anyways, I was gonna post on that, and this thread seems in a similar vein.
|
|
|
|
Re: It's called "static recompiler"
[Re: safreen]
#249090 - 03/17/11 10:04 AM
|
|
|
> I need your help with stuff related to MAME:
>
> - Will you help me find the game in MAME that would be the least problematic for
> this?
To be general purpose you need to find a game that would be most problematic, if it can't handle the worst case then it's not worth doing.
> - Will you help me locate necessary files, functions and variables so I know where to
> start?
To be able to do what you're trying to do then you should be able to do that yourself much quicker than asking questions to someone who is probably in another time zone.
> I'll tell you about it after you answer this question: How much of the code DRC
> handles currently in MAME - is it just for some games and ONLY FOR SOME PARTS of the
> code, and could it be implemented so that WHOLE game (any game) can be cached with
> DRC?
The DRC runs all the code, it never drops back to an interpreter.
> That's if your assumptions are correct and if you ignore all the other benefits I
> mentioned, but what if I manage to get 25 times speed increase anyway, would you be
> interested then?
As long as your approach works off the original roms, can start running the game as quickly as mame already does and still achieves a 25 times speed increase then yes that would be interesting.
You can't legally distribute a machine translation of a copyright file, so you have to be able to work off the original roms (because a real user can dump their own roms). You'll need to rebuild your translated code when a bug is fixed in the translator.
You need to be able to cope with indirect jumps. Jump tables or pointers might be calculated at run time, so they might not be available when you need them. Even if the jump table is available, you might not be able to work out what size they are.
static recompilation is very useful for porting games from one platform to another, you can special case bits by hand to make it work & even change the resulting source code before compiling it. MAME has to be able to cope with running any software, if you write software for galaxian hardware then it should run in MAME by just naming the roms correctly.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Took ya all long enough....
[Re: mogli]
#249095 - 03/17/11 02:37 PM
|
|
|
> What's fascinating is, as I always stop at the main page first and look at the
> then-current mamedev quote, I saw this RB quote today, and was wondering whether a
> multiple core machine could run your OS, etc, on one; then have another core perform
> machine language game operation...but...then it'd have to be translated before video
> output, huh? Anyways, I was gonna post on that, and this thread seems in a similar
> vein.
The quote changes every time you reload the page, there is no "current mamedev quote".
As far as OS services on a separate core from MAME itself, every OS I know of already does that automatically. And the overhead of the translation for a caching DRC is super-small, especially since it only happens once per piece of code in any half-modern emulator.
|
|
|
| H@P |
|
Lurker in perpetuity
|
|
|
|
|
Reged: 09/22/03
|
|
Posts: 234
|
|
Loc: Seattle area
|
|
|
|
Send PM
|
|
|
Re: Emulator: Interpreter vs. Compiler?
[Re: drewcifer]
#249100 - 03/17/11 03:59 PM
|
|
|
> Something about the post above tickled a memory of mine.
If you get a "What the ... ?" post out of him, you might be onto something.
H@P
|
|
|
|
Re: Took ya all long enough....
[Re: R. Belmont]
#249165 - 03/18/11 04:53 AM
|
|
|
> The quote changes every time you reload the page, there is no "current mamedev
> quote".
Exactly. 'Then-current'.
>
> As far as OS services on a separate core from MAME itself, every OS I know of already
> does that automatically. And the overhead of the translation for a caching DRC is
> super-small, especially since it only happens once per piece of code in any
> half-modern emulator.
I was thinking along the lines of: have one core do the regular OS stuff, another core do the machine language part. No?
|
|
|
|
Re: It's called "static recompiler"
[Re: R. Belmont]
#249167 - 03/18/11 05:01 AM
|
|
|
> > It's not "derived" work in usual sense, it's "reverse-engineered" and this wording
> > can be important, but I argue it would be a "remake" with its own copyright just
> like
> > if you get a camera and film Star Wars remake with your friends as actors, that's
> > completely different than if you took camera and film the actual movie in theater.
>
> Sure it's derived. If I translate "The Shining" into Spanish, it's still Stephen
> King's copyrighted work. That's all a static recompiler does: translate code into
> another language.
A better example might be taking the soundtrack to Star Wars on reel-to-reel (which my friend's father actually had, btw) and converting it to MP3. It's the same "content" just the method of delivery is different. This does not give you copyright on the MP3s.
|
|
|
Index 
Threaded 
Emulator: Interpreter vs. Compiler?
Reply
[Re: 
