PCSX Development

[M.I.K.e7]

Correct me if I'm wrong, but I've just taken a look at several MIPS to x86 dynarecs and all seem to have the same unoptimised solution for SLT/SLTI.

All seem to make a comparision between the two registers or the register and the immediate, and then write the set EAX to the result of the comparision like this:

cmp Rs, Rt
setl  eax

To make sure that only one or zero is on EAX they either do a XOR EAX, EAX beforehand or an AND EAX, 1 afterwards.

But since comparisions in computers are just subtractions and SLT/SLTI do signed comparisons, it should be possible to just do a subtraction and shift the sign of the result to the bottom of the register like this:

sub Rs, Rt
shr Rs, 31

Since the logical shift to the right only keeps the former sign we don't have to care about what the register contained in addition, thus saving one instruction.
Mind you, I haven't tested it yet, but I guess it should work.

Unfortunately it won't work for SLTU or SLTIU, since these perform an unsigned comparision.

Maybe I'm just a little bit pedantic, saving a single instruction, but I think SLT might be used quite frequently and it's probably not the only instruction that could be optimized.

Not to mention that SLT should often occur in combination with one of the branch instructions, and those two could be combined to generate the appropriate condition code instead.

BTW, does PCSX actually use the dynarec?
Even with grep I seem to be unable to locate where the emulator calls the functions declared in the dynarec...

[jivera]

M.I.K.e7: Correct me if I'm wrong, but I've just taken a look at several MIPS to x86 dynarecs and all seem to have the same unoptimised solution for SLT/SLTI.

I've been noticing things like that too - PCSX at least seems to use a direct mapping of MIPS instructions to x86 instructions with a little bit of constant folding. As far as I can tell, it does not make any attempt to make better use of registers for holding temporary values, for example. However, at the same time, I'm curious how beneficial it would be to devoting much time to adding optimizations like these.

With regard to your specific optimization about SLT/SLTU, yeah, I'll agree that makes sense.

BTW, does PCSX actually use the dynarec?
Even with grep I seem to be unable to locate where the emulator calls the functions declared in the dynarec...

It never directly calls the dynarec functions - the function pointers are stored in a struct called psxRec. When the recompiler is enabled, the pointer psxCpu is set to point to psxRec and otherwise to psxInt. The end result is something similar to C++'s virtual functions.

One of the things I'm interested in right now is finding a good documentation of the x86 machine code layout for all the instructions. I found a decent one in Windows help format, but it doesn't go into much detail about how registers and immediate values are included in the instruction.

-jivera

[zenogais]

Jivera here is the best doc I've found for the encodings, its what I'm using. Its for the NASM assembler:

Nasm Docs

[M.I.K.e7]

Originally Posted by jivera

I've been noticing things like that too - PCSX at least seems to use a direct mapping of MIPS instructions to x86 instructions with a little bit of constant folding.

Do you mean by constant folding that it combines a LUI with a following ORI with the same destination register to a single move instruction on x86?

Originally Posted by jivera

With regard to your specific optimization about SLT/SLTU, yeah, I'll agree that makes sense.

Good, then I'm not totally insane yet.

Originally Posted by jivera

It never directly calls the dynarec functions - the function pointers are stored in a struct called psxRec. When the recompiler is enabled, the pointer psxCpu is set to point to psxRec and otherwise to psxInt. The end result is something similar to C++'s virtual functions.

Seems I have to take a closer look, thanks.

Originally Posted by jivera

One of the things I'm interested in right now is finding a good documentation of the x86 machine code layout for all the instructions. I found a decent one in Windows help format, but it doesn't go into much detail about how registers and immediate values are included in the instruction.

Unfortunately instruction endcoding in x86 is a real pain, which is one of the reasons why I'd rather do a code generator on the PowerPC.
But you could check out the following:
The IA-32 Intel® Architecture Software Developer's Manual, Volume 2: Instruction Set Reference

[jivera]

M.I.K.e7: Do you mean by constant folding that it combines a LUI with a following ORI with the same destination register to a single move instruction on x86?

More or less - it's a bit more generic than that. Instructions that load a fixed value into a register set a flag that marks that the register's value is known. As it progresses, anytime it finds an instruction that uses either a constant register and an immediate or two constant registers, it simply stores the result in the destination register. Only if one of the two are unknown does it output instructions.

Unfortunately instruction endcoding in x86 is a real pain, which is one of the reasons why I'd rather do a code generator on the PowerPC.

Yeah, so I've heard.

But you could check out the following:
The IA-32 Intel® Architecture Software Developer's Manual, Volume 2: Instruction Set Reference

Hm, I'll check that out.

[jivera]

I just finished playing around with GCC's built-in support for vector instructions (MMX/SSE/etc.), and I think I may rewrite some of the code to take advantage of it (at the recommendation of shadow). It would give the benefit of making it easier to write the code to do different vector and matrix operations and allow GCC to better optimize for them on processors that may take advantage of it (while still generating backwards compatible code for systems that can't).

I'm wary to make a decision like this that would damage support for Visual C++, but mingw could still provide for the Windows port. (However, at the same time I don't have Visual C++ so I couldn't check changes I make on it anyways, so unless any other developers are interested in compiling using VC++, there's probably no point in me making extra effort on behalf of it.)

-jivera

[zenogais]

I have Visual C++ 6 if you would require someone to check the compatability. While its not the latest version(.NET) it should work fairly well. Also just wanted to pointed out something I've noticed in PCSX:

*The Dynarec(Dynamic Recompiler) engine has no support for a Translation Cache, this cache may very well speed up the dynarec by quite a bit.

Basically if you don't know a Translation Cache functions very much like a CPU cache by checking to see if it has already translated the instruction at that location in memory. In the case of PCSX this is the Playstation's memory. If it does contain a translation cache, since I'm only 98% sure on this, can you please tell me where.

[jivera]

zenogais: I have Visual C++ 6 if you would require someone to check the compatability. While its not the latest version(.NET) it should work fairly well.

Alright, we'll see (I still haven't decided to take advantage of GCC's stuff yet or not, but I'm leaning in favour of it).

*The Dynarec(Dynamic Recompiler) engine has no support for a Translation Cache, this cache may very well speed up the dynarec by quite a bit.

I think you're mistaken. Beginning at line 428, ix86/iR3000A.c defines the function execute which is used to execute a single block of code:

__inline static void execute() {
        void (**recFunc)();
        char *p;

        p =     (char*)PC_REC(psxRegs.pc);
        if (p != NULL) recFunc = (void (**)()) (u32)p;
        else { recError(); return; }

        if (*recFunc == 0) {
                recRecompile();
        }
        (*recFunc)();
}

You can see recFunc is a pointer to a function pointer. The first half of the function sets it up to point to where the function pointer should be in memory and if it's zero, then it runs recRecompile to save the function pointer to that memory location. Then, after recRecompile returns, execute may dereference recFunc and call the function pointer.

As has been said before, the dynamic recompiler wouldn't offer much improvement if it didn't save recompilation results.

-jivera

[zenogais]

Thanks jivera, I was just curious if it did or not. Just let me know if you need VC++.

[TheGodfather]

Hello jivera!
Thanks for continue with the development of the best PSX emu available.

Also I really would like to read your progress here or somewhere else, please keep us informed about your progress with the emu.

Thanks again
Bye

[jivera]

TheGodfather: Thanks for continue with the development of the best PSX emu available.

No problem. Thanks for the support. :-)

Also I really would like to read your progress here or somewhere else, please keep us informed about your progress with the emu.

I'll see if I can find some way to easily maintain a list of news articles on my website so I can do just that. For the most part, right now I'm just focusing on learning the ins and outs of the source code as well as reading up on some of the relevant documentation so I can make helpful improvements. Once I start adding improvements, however, I'll be sure to keep updates.

-jivera

[jivera]

In an effort to be able to possibly improve the quality of the dynarec and interpreter, I've been trying to find documentation about some of peculiarities of the R3000A, particularly load and branch delays. I understand the idea of loads being delayed until after the next operation as well as operations after a branch still being executed, but I can't seem to find any documentation that gives precise explanations about this behaviour. Here are some of my questions (obviously the most important answer to these is if they're even relevent):

* Do PSX games use dynamic code generation?
The GameBoy Advance has different access speeds for different segments of RAM, so critical loops and code will get copied by the program into this area for execution rather than the game's ROM. Is there any idiom that parallels this or can it safely be assumed (at least in the common case) that writable and executable memory will never overlap? Are there any games known to either dynamically generate code?

* Which instructions have delay slots and how exactly do they work?
As far as I know, only branch/jump and load instructions have delays. I played around with PCSpim, the emulator my Digital Systems class uses for learning MIPS, to understand delays, but it only seems to support branch delays. I've emailed my professor even to ask about this, but he doesn't seem to know either and hasn't received a response back from the school responsible for writing the program yet.

* What instructions are valid in a delay slot?
I have read that any instruction that does not have its own delay slot may be placed in a delay slot. This would leave me to believe that an efficient solution to emulating this behaviour would be whenever there's a delayed operation, reorder the instructions so the delay slots appear before the current instruction.

Rethinking this idea, however, I cannot imagine multiple consecutive loads would be invalid so maybe that was not a correct explanation. I have not yet thought out the best solution to reordering a series of loads that may be dependant upon each other, but I'll look into it and I'm sure there can't be _too_ many special cases. (I can see a few other flaws with this, but as said, it's still very in the rough.)

Also, what's the rule with multi-cycle instructions or branches in a delay slot?

* Do stores technically have delays too?
A load delay is caused by the fact that an access from memory takes a cycle before it arrives in the register file. Is there a cycle delay before a store affects memory or will it never have a significance? e.g.

sw $t0, 0(t2)
lw $t1, 0(t2)

Is this a valid instruction pattern? If so, afterwards does $t1 hold the original value at 0(t1) or the same value as $t0? How about this:

lw $t0, 0(t1)
sw $t0, 0(t1)

Is this a valid instruction pattern? Would this instruction pattern swap the values stored in $t0 and at 0(t1)? If so, this would force me to add a little extra logic to my idea from earlier about swapping delay slots and their respective instructions (otherwise 0(t1) would simply be updated to hold the value of $t0).

* Branches upon branches
Is a branch instruction valid in another branch's delay slot? I've heard this is invalid, but the more important rule is what's the expected behaviour if it's possible that a PSX game may include code using this?

* Breakpoints
Since one of the features I'm interested in adding is better breakpoint support, I wanted to know if there's any common requirements for placement of breakpoints (such as not allowed to be in delay slots)?

I think that'll be enough for now... :-)

-jivera

Edit: Maybe one way to find the "proper" behaviour for these conditions is to write up some test framework that I can run on other highly compatible PSX emulators and just look at what results they give. (Perhaps even better would be if someone could run this test suite on a Net Yaroze or something to guarantee what the correct behaviour is... dunno how feasible this is though.)

[M.I.K.e7]

Originally Posted by jivera

* Do PSX games use dynamic code generation?

Generally I have no idea. I guess it might depend highly on the specific game, since all code has to be loaded into the RAM to be executed anyway, unlike the GBA where you have to option of the slow ROM or the faster Work-RAM (I'm no GBA programmer but I guess they even use the 16-bit Thumb instruction set in the ROM and the 32-bit ARM instruction set in WRAM, but that's off-topic anyway...).
Maybe Xeven has more information about what specific games do.

Originally Posted by jivera

* Which instructions have delay slots and how exactly do they work?
As far as I know, only branch/jump and load instructions have delays.

That's correct for the R3000A, but it has changes a little since, which is probably why your professor isn't sure about it and why your simulator behaves differently.
Originally MIPS was designed to be very simple and had no hardware interlocking in the pipeline whatsoever (MIPS actually stands for Microprocessor without Interlocking Pipeline Stages).

One of the side effects of this is that when you try to access the destination register of a load instruction in the next instruction following it, the result is undefined because the value hasn't been loaded into the register yet, ie. the load operation is delayed, not the instruction in the delay slot! Most other processors would produce a so-called interlock until the data has been loaded. In fact from MIPS II onwards the processors actually do have interlocking for load instructions, which is probably the cause of your confusion.
A bit of architecture history: The R3000A belongs to MIPS I, while MIPS II is basically only the less known R6000. MIPS III is the R4000 family (ie. the N64 has no load delay slots), MIPS IV is R10000 and R5000, etc.
It's still good style to program if there were a load delay slot, because the interlock is basically a pipeline stall, and you surely don't want that! Not that it's important for an emulator anyway...
To make a long story short: I don't think that you have to care about load delay slots in an emulator, because it's the compiler's or assembly programmer's job to make sure that such instruction combinations don't happen. If you want to be on the sure side you could monitor if the destination register of a load is used directly after the instruction, just for debugging purposes.

The other side effect (which was actually intended and thus is still present in all MIPS processors up to now) is that the instruction directly following a branch or jump instruction is executed before the branch is actually performed. Think of it as the branch calculating the branch target or checking the branch condition first, while the next instruction executes, and then the program counter is adjusted.
For emulation purposes you just interpret or generate the code for the instruction in the branch delay slot before you deal with the branch instruction, because that instruction is executed, no matter if the branch is taken or not (it's different with branch-likely, but that's only present from MIPS III onwards). Also the instruction has to be "safe" by defintion, or a NOP if a safe instruction cannot be found, ie. you shouldn't have to care that the instruction in the branch delay slot might change the condition for the branch.
A bit of processor theory: All processors with a pipeline fetch the instructions following a branch (unless an optional branch predictor tells them otherwise), and if the branch is taken the whole pipeline has to be cleared. The designers of the MIPS wanted to give the instruction in the branch delay slot, which is fetch anyway, some purpose, thus it is executed before the branch finishes.
So why didn't MIPS have branch prediction? Well, it was 1985 and they wanted to create a simple and cheap processor. It doesn't even have a real MMU, just a TLB that throws an exception when it a page translation isn't present...

I hope it's a little clearer now.

Originally Posted by jivera

* What instructions are valid in a delay slot?

Good question, I actually have no real information about that. But I doubt that it would be good style to put a branch instruction in a branch delay slot!
Since processors of the MIPS I architecture probably don't check, I guess everything would be possible in theory, but I don't think that anyone will use anything but "safe" instructions.

Originally Posted by jivera

Rethinking this idea, however, I cannot imagine multiple consecutive loads would be invalid so maybe that was not a correct explanation.

From my explanation above it should be clear that the only real problem would be the branch delay slot, and you're right that a sequence of load instructions is just fine, as long as one load doesn't use a base register that is loaded just before, because then the result simply is unpredictable.

Originally Posted by jivera

Also, what's the rule with multi-cycle instructions or branches in a delay slot?

Apart from loads and branches the only real multi-cycle instructions I know of are multiplication and division, but these are simply started and then continue calculating in a separate multiplication unit, even if an exception should occur!
This can be a slight problem; quoting "See MIPS Run" by Dominic Sweetman:

The integer multiplier has its own separate pipeline. Operations started by instructions like mult or div, which take two register operands and feed them into the multiplier machine. The program then issues an mflo instruction (and sometimes also mfhi, for a 64-bit result or to obtain the remainder) to get the results back into a general-purpose register. The CPU stalls on mflo if the computation is not finished; so a programmer concerned with maximising performance will put as much useful work as possible between the two. In most MIPS implementations a multiply takes 10 or more clock cycles, with divide even slower.
The multiply machine is separately pipelined from the regular unit. Once launched, a multiply/divide operation is unstoppable even by an exception. That's not normally a problem, but suppose we have a code sequence like the following where we're retrieving one multiply unit result and then immediately firing off another operation:

   mflo  $8
   mult  $9, $10

If we take an exception whose restart address is the mflo instruction, then the first execution of mflo will be nullified under the precise-exception rules and the register $8 will be left as though mflo had never happened. Unfortuately, the mult will have been started too and since the multiply unit knows nothing of the exception will continue to run. Before the exception returns, the computation will most likely have finished and the mflo will now deliver the result of the mult that should have followed it.
We can avoid this problem, on all MIPS CPUs, by interposing at least two harmless instructions between the mflo/mfhi on the one hand and the mult (or any other instruction that starts a multiply unit computation) on the other.

I doubt that it's important for an emulator (especially since you won't be simulating the pipeline), but it's interesting nevertheless.
BTW, according to "MIPS RISC Architecture" by Gerry Kane and Joe Heinricht the cycle timing of multiply/divide instructions for the R3000 are: 12 cycles for MULT/MULTU and 35 cycles for DIV/DIVU. But I also don't think that this is important for an emulator to keep track of, if we assume that the programmer or compiler put enough code between these instructions and MFLO/MFHI for the operation to finish the computation by that time.
A more interesting question for the dynarec would be: When should the multiplication or the division be performed? When the instruction is found that starts the computation or when the result of that computation is referenced?

Originally Posted by jivera

* Do stores technically have delays too?
A load delay is caused by the fact that an access from memory takes a cycle before it arrives in the register file. Is there a cycle delay before a store affects memory or will it never have a significance? e.g.
sw $t0, 0(t2)
lw $t1, 0(t2)
Is this a valid instruction pattern?

No, stores have no delay slots, and the code example above shouldn't be a problem. Stores simply write the data to the cache and are done. The following load will still find the data in the data cache.

Originally Posted by jivera

How about this:
lw $t0, 0(t1)
sw $t0, 0(t1)
Is this a valid instruction pattern?

It's not valid, because when the store is executed the value of register $t0 is still undefined.

Originally Posted by jivera

* Branches upon branches
Is a branch instruction valid in another branch's delay slot? I've heard this is invalid, but the more important rule is what's the expected behaviour if it's possible that a PSX game may include code using this?

I don't think it's totally impossible, but it certainly would be very, very bad code, and I doubt that you'll find that in practical code.

Originally Posted by jivera

* Breakpoints
Since one of the features I'm interested in adding is better breakpoint support, I wanted to know if there's any common requirements for placement of breakpoints (such as not allowed to be in delay slots)?

Good question, and I have no answer right now...

Originally Posted by jivera

I think that'll be enough for now... :-)

I hope that at least some of my information was useful to you...

[jivera]

M.I.K.e7: Apart from loads and branches the only real multi-cycle instructions I know of are multiplication and division, but these are simply started and then continue calculating in a separate multiplication unit, even if an exception should occur!

Okay, that makes things nice. I guess if we really wanted to be accurate, count the cycles between the mult/div op and the mfhi/mflo op and just add a bit if it doesn't hit the minimum. (Probably just calculate immediately too for simplicity sake - I see no advantage in delaying.)

Stores simply write the data to the cache and are done.

Ohh, I completely forgot about cache. The reason I was thinking a store might have a delay is because I knew a load delays so it can fetch from memory and I thought a store might need to go through the same delay to write into memory, but if it hits the cache first so the next load gets the right value that would make sense (and make things easier. :-)

To make a long story short: I don't think that you have to care about load delay slots in an emulator, because it's the compiler's or assembly programmer's job to make sure that such instruction combinations don't happen.

Okay, I was under the impression that the value of destination register for a load was unchanged until after the next instruction, not undefined. I agree with just making a warning or something when it has a pipeline hazard or something.

-jivera

[linuzappz]

hey, jivera, goldfinger is coding an API for recompilers which as he told me could be easily added to pcsx, it's still in development but you should contact him, i'm sure that it will be a nice addition for pcsx... of course when it's usable .

[Cyberman]

I have been for several months wanting to add a certain something to PCSX a Gnu Debug Compatible Debugging interface. Sort of like an integrated debugger but GDB compatible. I've found this a great tool for GBA playing at times

I doubt this would work too well in Dynamic REC mode. Also I doubt it would be particularly fast though it doesn't need to be. It might be KEY in improving the already good compatibility with the PS1. Small 'program' glitches can be found and detailed what is going wrong by steping through a section of code and undoing execution to find what is causing the emulator to trip up.

This would also relieve PCSX of needing a debuging console. This is because one can using the NETWORK capability of GDB with an existing debugger for the processor (MIPS R3K in this case). I believe CodeInsight supports it.

I haven't been able to find much on the debugging interface PCSX supports. So I'm pretty clueless with the code though I have managed to add a new plugin type for memcard saves (this might seem insane but there is a method to the madness). In case someone every makes a PocketStation Emu compatible with the Memcard interface (now that would be a complete PS1 emulation LOL).

Since these use the ARM thumb processor might take a bit of time to get one of those working. Might be worth a bit of fun

Cyb

[jivera]

linuzappz: hey, jivera, goldfinger is coding an API for recompilers which as he told me could be easily added to pcsx, it's still in development but you should contact him, i'm sure that it will be a nice addition for pcsx...

Sounds interesting.

of course when it's usable .

:-)

Cyberman: I have been for several months wanting to add a certain something to PCSX a Gnu Debug Compatible Debugging interface. Sort of like an integrated debugger but GDB compatible. I've found this a great tool for GBA playing at times

You read my mind! That's exactly one of the features I've been considering adding. I loved that about VirtualBoyAdvance (except how the Windows and Linux versions had different feature sets so to do complete debugging I had to use both).

I doubt this would work too well in Dynamic REC mode.

Probably not... we'll see (I'll try to add to the interpreter first though).

This would also relieve PCSX of needing a debuging console. This is because one can using the NETWORK capability of GDB with an existing debugger for the processor (MIPS R3K in this case). I believe CodeInsight supports it.

Hm... can you elaborate on this?

I haven't been able to find much on the debugging interface PCSX supports.

I don't know that it supports one, but I haven't finished going through all the code yet.

*runs off to find how to interface with GDB*

-jivera

[Cyberman]

Originally Posted by jivera

Cyberman: I have been for several months wanting to add a certain something to PCSX a Gnu Debug Compatible Debugging interface. Sort of like an integrated debugger but GDB compatible. I've found this a great tool for GBA playing at times

You read my mind! That's exactly one of the features I've been considering adding. I loved that about VirtualBoyAdvance (except how the Windows and Linux versions had different feature sets so to do complete debugging I had to use both).

Probably not I asked linuzappz about it a few times but I know he's busy with PCSX2 now. (which would be cool to have a GDB interface added onto as well might make making demos for the PS2 .. easier if not more interesting ).

I used VBA with Visual Ham and hamlib for some source level debugging and playing with GBA developement (it's pretty cool to watch your code go crazy instead of compile crash burn and inspect the pieces).

Originally Posted by jivera

This would also relieve PCSX of needing a debuging console. This is because one can using the NETWORK capability of GDB with an existing debugger for the processor (MIPS R3K in this case). I believe CodeInsight supports it.<