Remember Fabrice Bellard's jslinux 80486 emulator? Inspired by his idea, I'm trying to write a PowerPC emulator in JavaScript. The instruction set is a lot easier of course than the x86 variable-length CISC, which I barely understood but couldn't implement. I've so far implemented 39 operations, which covers most of the fixed-point storage-type functions. If anyone would like to take a look at it, or give me some advice to improve it, here it is: http://azabani.com/cgit.cgi/jsppc/tree/jsppc.js
Name:
Anonymous2011-05-22 2:48
Name:
Anonymous2011-05-22 2:50
This is more nitpicking, but your op object's formatting makes my eyes burn. Space your functions out better.
Name:
Anonymous2011-05-22 2:52
>This is more nitpicking, but your op object's formatting makes my eyes burn. Space your functions out better.
In my attempts to make each instruction's function take only a few lines maximum, I've fucked up neat formatting. I'll see what I can do to improve it, even if that means making each instruction 10+ lines. Thanks.
Name:
Anonymous2011-05-22 3:10
While I'm cleaning up the formatting of the op object's functions (or afterwards), could anyone well-versed in PowerPC assembly go over some of my operations and check that the implementation behaviour is correct? I've tested a few of the operations, but not all of them, and that would be a big task, so if anyone else could help me, that would be great.
Name:
Anonymous2011-05-22 3:17
>>3 This is more nitpicking, but your op object's formatting makes my eyes burn. Space your functions out better.
I've committed a change that improves the spacing and formatting of the operation functions.
I've never programmed on PPC, but doesn't it have flags or something?
Name:
Anonymous2011-05-22 3:26
>>7
Flags? What kind of flags? I know that PowerPC sometimes stores additional information outside the GPRs and FPRs, such as in the 64-bit fixed-point exception register. I'm creating the data structures that I need for the operations as I go.
>>8
Something like x86's FLAGS, carry flag, zero flag, parity flag and shit.
Name:
Anonymous2011-05-22 3:40
>>9
As far as I know (though I may be wrong seeing as my understanding of PowerPC architecture spans under 24 hours), this is implemented as bit fields in the instruction, or sourced from data in a special register. In the former case, that means within the 32 bits of the instruction, which contains the OPCODE/XO fields plus operands, there may be one or more bit fields with flags for the instruction somewhere in the 32 bits. In the latter case, bit fields may be sourced from e.g. the fixed-point exception register.
Name:
Anonymous2011-05-22 3:44
Did you look at Bellard's emulator? Functions are going to be super slow; use a giant switch statement.
Name:
Anonymous2011-05-22 3:46
use a giant switch statement.
aka UR MOM
Name:
Anonymous2011-05-22 3:48
>>11 >>12
I haven't had a good look at his emulator yet, even though I found the unminified one on GitHub. This is mostly because of all those one- or two-letter variable names that he obfuscated the code to (though he says that he will release it later).
What I was going to do initially was have a switch statement in jsppc.cpu::step, which then called the functions in jsppc.op, but if the performance penalty is going to be as bad as you claim (i.e., with all that stack mashing and no inlining) then I might just put it back into a pure switch statement.
>>13
The variable names are abbreviations for x86 instruction fields (ModRM, Disp, SIB, etc.) He probably named them that way himself.
Name:
Anonymous2011-05-22 3:56
>>14
This is probably just my weakness as a programmer then. I couldn't grok what the fuck the code was on about, at all. It could partially have been made more complex for me to follow because of x86's variable-length instructions that must be broken up in different ways.
Name:
Anonymous2011-05-22 3:59
weakness
like UR COCK
broken
like UR COCK
Name:
Anonymous2011-05-22 4:01
>>16
So much summer. Well, it's winter where I am, but still.
I've made a few more commits and added some more operations.
Name:
Anonymous2011-05-22 4:05
commits
unlike UR GIRLFRIEND, WHO IS FUCKING UR BEST FRIEND EVERYDAY BECAUSE YOU HAVE A broken COCK
I have just realised that everywhere where the manual says that the implementation should EXTS a number (extend sign bit leftwards until 64 bits for them, and 32 bits for me) I haven't done it. I think that would cause problems. Shit, now I have to go through all my operations and check for missing EXTS.
Name:
Anonymous2011-05-22 4:26
Now I'm buttmad.
Name:
Anonymous2011-05-22 6:06
Fuck, just realised I've done a lot of things wrong in my operations' implementations. Welp, looks like I'm starting those again.
It's a good thing you haven't noticed it later. I'm sorry for not being able to help, but I'm interested in your development.
Name:
Anonymous2011-05-22 11:08
Computer Science is a BULLSHIT degree.
Name:
Anonymous2011-05-22 22:49
PowerPC isn't that simple. Try MIPS or ARM.
Name:
Anonymous2011-05-23 1:37
>>26
I'm pretty sure those are less glorious. It's too bad, though, that for a PPC emulator to be useful at all, you'd need to implement a shitload of custom chips for your actual target platform—consider that there still isn't an emulator for early New World Macs and you start realising that you might be a little crazy.
>>27
ARM is everywhere though. You could make a DS emulator and call it JSDS.
Name:
Anonymous2011-05-23 6:49
Finally, I have finished fixing up all the existing operations so they are endian aware. You see, the arrays used for memory are stored in host endianness, which could be little-endian if the browser is on e.g. x86. PowerPC is big-endian. Not being aware of this and flipping bytes if necessary caused problems. Now, my main concern is that calling getter/setter functions just to read/write memory is going to do a lot of stack thrashing, and I believe that it is going to severely penalise the performance of the emulator. I did send Fabrice an email though, so hopefully if he replies I'll have some advice from the man himself about optimising the code.
Name:
Anonymous2011-05-23 6:49
>>24
Thanks. Fortunately, I've finished fixing up the existing instructions that I've implemented, and it looks like there are no other big conceptual problems (yet).
Name:
Anonymous2011-05-23 18:02
Giving one of the more interesting threads a bump.
What do you plan to emulate besides the processor?
Name:
Anonymous2011-05-23 18:11
>>32
I would really like to know that. The 486 emulator, after all, was a whole PC; but Macs, Pegasos machines, PPC-enhanced Amigas, embedded POWER system users, z/OS mainframes, and the current generation of consoles (did I miss anything?) all rely on a shit-ton of custom copper and silicon to get anything done. It wouldn't be a complete machine like jslinux.
I would suggest trying to go after early PPC Macs, because they're most likely to be simple to implement, and also there's the source for one accessible from here, Sheepshaver: http://sheepshaver.cebix.net/#download
>>33
The Pegasos boards used off-the-shelf components, same with the AmigaOne boards. The documentation for all the parts isn't public, but no-one involved had the money for custom chips.