Some (possibly) New Ideas for RPCS3

[derpf]

I'm sorry, but it's pretty clear you did not understand my post. I discussed binaries, dynamic loading, and also the decoding stage.

-[Unknown]

Well, stepping by what you wrote it's obvious that what you're saying is wrong:

Certainly no game binary is 10GB.

http://www.examiner.com/article/file-siz...d-xbox-360

Perhaps we have a different idea of "game binary" here. Game "binary" is everything that makes up the game on the medium, not the max capacity of the medium itself. You also have a skewed description by thinking that RAM size must be 1:1 with the size of a binary itself, which couldn't make any sense.

Final Fantasy 7 for PSX takes up over 700 MB for disc 1's total binary image, including all code and data of the entire game; PSX has 2 MB of RAM total. Based on your assumption that a binary can't be larger than the size of RAM, how could the Playstation run the game then?

Game binary usually refers to the executable code, not game data which would be sound and graphic files and such.

When you load a game, either a Windows .exe, a .elf, or something else, you always load that program into memory for the CPU to fetch and execute the instructions. On a really basic level, that is basically what an .exe is, a long list of instructions for the cpu to follow. But this is only the ".exe" part of a game. Everything else such as graphics gets loaded into RAM/VRAM as it is needed, and removed when it isn't needed any more. This can be cached to ram in order to improve loading times (and a smart OS probably will if the data is loaded/unloaded frequently), but hardly any more than that.

Also, [Unknown] is one of the big guys from ppsspp, assume he knows what he is talking about

That's not strictly true as executables also contain data (only executable sections like .text have code). You can very well pack all of the game data into the executable itself, it's just that nobody in their right mind does that beyond small things like icons or .xpm images.

[ssshadow]

I'm sorry, but it's pretty clear you did not understand my post. I discussed binaries, dynamic loading, and also the decoding stage.

-[Unknown]

Well, stepping by what you wrote it's obvious that what you're saying is wrong:

Certainly no game binary is 10GB.

http://www.examiner.com/article/file-siz...d-xbox-360

Perhaps we have a different idea of "game binary" here. Game "binary" is everything that makes up the game on the medium, not the max capacity of the medium itself. You also have a skewed description by thinking that RAM size must be 1:1 with the size of a binary itself, which couldn't make any sense.

Final Fantasy 7 for PSX takes up over 700 MB for disc 1's total binary image, including all code and data of the entire game; PSX has 2 MB of RAM total. Based on your assumption that a binary can't be larger than the size of RAM, how could the Playstation run the game then?

Game binary usually refers to the executable code, not game data which would be sound and graphic files and such.

When you load a game, either a Windows .exe, a .elf, or something else, you always load that program into memory for the CPU to fetch and execute the instructions. On a really basic level, that is basically what an .exe is, a long list of instructions for the cpu to follow. But this is only the ".exe" part of a game. Everything else such as graphics gets loaded into RAM/VRAM as it is needed, and removed when it isn't needed any more. This can be cached to ram in order to improve loading times (and a smart OS probably will if the data is loaded/unloaded frequently), but hardly any more than that.

Also, [Unknown] is one of the big guys from ppsspp, assume he knows what he is talking about

That's not strictly true as executables also contain data (only executable sections like .text have code). You can very well pack all of the game data into the executable itself, it's just that nobody in their right mind does that beyond small things like icons or .xpm images.

I know, that's why I said "On a really basic level, that is basically what an .exe is, a long list of instructions for the cpu to follow. " It's certainly the most relevant part in this context.

[Ontakeio]

Yes, I mean the whole game not just the code. Did not mean to start arguments but I just meant that the whole code can be fetched and decoded prior to execution and the decoded instructions can be transferred into labels of commands.

When labels of commands are read by emu, appropriate functions can be called to immediately change RPCS3's state without having to decode as you play.

That is what I meant not bytecode, just with another parseable code that would not require instruction decoding of PowerPC code.

[[Unknown]]

So, let me ask you again, if you're so convinced about these things, why aren't you trying them yourself, and building proof of concept examples? Why waste all the time with this MPD silliness?

I mean, you're providing some entertainment, don't get me wrong.

But I'm thinking you probably don't believe these things yourself (if you did, you'd be researching them and trying to gain knowledge and test them), and just are hoping to send someone on a wild goose chase. That's a shame.

-[Unknown]

[Nekotekina]

Yes, I mean the whole game not just the code.

It makes so much sense so I want to close this thread immediately.

[gamenoob]

Yes, I mean the whole game not just the code. Did not mean to start arguments but I just meant that the whole code can be fetched and decoded prior to execution and the decoded instructions can be transferred into labels of commands.

When labels of commands are read by emu, appropriate functions can be called to immediately change RPCS3's state without having to decode as you play.

That is what I meant not bytecode, just with another parseable code that would not require instruction decoding of PowerPC code.

But on runtime instruction will be changed, How can you possibly decode earlier? Its not like encoding a set of frames(movie), its a realtime application emulation we are talking about.

[derpf]

Yes, I mean the whole game not just the code. Did not mean to start arguments but I just meant that the whole code can be fetched and decoded prior to execution and the decoded instructions can be transferred into labels of commands.

When labels of commands are read by emu, appropriate functions can be called to immediately change RPCS3's state without having to decode as you play.

That is what I meant not bytecode, just with another parseable code that would not require instruction decoding of PowerPC code.

But on runtime instruction will be changed, How can you possibly decode earlier? Its not like encoding a set of frames(movie), its a realtime application emulation we are talking about.

As far as we know, PS3 games cannot be polymorphic, so you can well do the fetching and decoding ahead of time. I highly doubt this would bring you much over the current system unless you want to waste a huge amount of memory.

[androidlover]

If all code can be decoded ahead of time before playing, the emulator can simply work like how ontakeo said, no? Wouldn't that make it faster if it was all decoded ahead of time and cached? Sounds like it would be potentially faster than a dynamic recompiler because the dynarec still has to decode as you play, even if it stores the decoded instructions in RAM.

[flashmozzg]

don't think that decoding the code is bottleneck right now.

[gamenoob]

Are you asking that, people should de-compile game code to something workable and then recompile to x86? That is an enormous task. And it is not generic either,you have to work for every game. Basically porting a huge collection ps3 games.