8 replies to this topic

[conso]

BouKiCHi released a new port of gpSP for dingux, this time with dynarec enabled.

Speed is great, but compatibility isn't that good any more and some games can hang a while at certain points.
Maybe some assembler/gpSP guru from this forum can help a little and review the changes he did to the recompiler-code.

Here's the porter's website with releases and sources: http://clogging.blog57.fc2.com/

[hlide]

BouKiCHi released a new port of gpSP for dingux, this time with dynarec enabled.

Speed is great, but compatibility isn't that good any more and some games can hang a while at certain points.
Maybe some assembler/gpSP guru from this forum can help a little and review the changes he did to the recompiler-code.

Here's the porter's website with releases and sources: http://clogging.blog57.fc2.com/

That's weird. I read EXT/INS/ROTR/ROTRV exist in JzMips (they are just slower than the real MIPS32R2 since they take at least 4 cycles instead of 1 cycle). But the guy is replacing those instructions by a bunch of instructions :/. Besides, if GPSP is emitting those isntructions in a delay slot of a branch, there will a *BIG* issue.

[Exophase]

Heh, "gpSP guru"

Several parties have done the non-MIPS32r2 modifications to gpSP now (zodttd, the various Chinese PMP makers, now this one).. shame that the source isn't getting back out there to prevent this. Maybe this will finally be that?

gpSP's stub code has ext in the delay slot of region checks for the memory stub handlers. This isn't really a big deal, because the ext is not used by the taken path of the branch; it would only be bad if the first instruction of the m_ext were destructive, which it isn't. I don't think anything is being used in a delay slot in emitted code.

I think a bigger concern is that in the emitted code at is being used indiscriminately as a temporary for the rotation ops, which is probably not okay. The macros in the stub code don't have this problem. Another big concern is that the cache invalidate instructions were just commented out altogether. The proper equivalent actually does need to be there.

The macros themselves are pretty bad (performance-wise), especially seb and seh. m_jal is rather concerning. I imagine that it's being done to get around some 256MB gaps between generated code and functions. This is a big problem for some ARM ports too. I'm sure there are much better ways to address this. At the very least, m_jal need not be used for the branches to internal subroutines. The $gp restore is also redundant given that save_registers performs this and is used before any external calls in order to follow proper ABI convention. The 16 byte stack allocation is also perplexing; does the ABI seriously require this?

All of the macros are saving/restoring off the stack, this shouldn't be necessary. The destination register can be used as a temporary, except when the source and destination are the same, in which case there should probably be a different macro entirely, where it applies.

But of course, fixing the bugs takes priority.

[trooper]

*/SNIP/*

Ooowww, I love it when you talk dirty.

Trooper

[conso]

thx for your review, exophase. I've forwarded this thread to Boukichi via email. I bet it'll be informative for him.

[hlide]

The 16 byte stack allocation is also perplexing; does the ABI seriously require this?

only EABI requires it as far as I recall (I saw it when I added a patch to psp-ggc to add -mpreferred-stack-boundary=n).

[conso]

Hi,

Thank you for telling the review to me.

I want to write reply to his comment directly,
but the forum registration doesn't work for me at the moment.


Instead,I'll reply to his comment in the mail.

I assumed that he reviews later code( not "slow" version ) to write this one.

Firstly,what I'm aiming to port gpSP is working the promgram on A320
properly.

not priority on performance.


> >At the very least, m_jal need not be used for the branches to internal
subroutines.

if he is saying about PSP version, then he is right.
but not right for a320 and other linux stuff.

The gpSP for A320 is genereted as a PIC( position independent code).
there is a code before changes to use m_jal.

>from mips_update_gba in mips_stub.S
> > sw $0, CHANGED_PC_STATUS($16)
> > jal update_gba # process the next event
> > nop
gcc puts a warning like this.

> >mips_stub.S: Assembler messages:
> >mips_stub.S:372: Warning: No .cprestore pseudo-op used in PIC code
And this is the result.

> > 108: ae00007c sw zero,124(s0)
> > 10c: 8f990000 lw t9,0(gp)
> > 110: 0320f809 jalr t9
> > 114: 00000000 nop
it jumps out like the valley where I don't know.
because $gp save nowhere in the code.

but I didn't know this.

> >The $gp restore is also redundant given that save_registers
performs this and is used before any external calls in order to follow
proper ABI convention.

Indeed,he is made it like this and I didn't find this until I read the forum.

> > lw $28, GP_SAVE($16)
However, the problem is where the $gp is stored.
I can't find the part anywhere in orignal assembler code.

Let me know where is the part if anyone can

( the original assembler code mips_stub.S was dated May-23-2007, it might be updated after this)

> > The 16 byte stack allocation is also perplexing;
does the ABI seriously require this?

The stack was a problem for porting.

There is an example for ABI(calling conversion).

C code:
void test(int value)
{
if (value)
value = 5678;
}

Generated code:
00400760 <test>:
400760: 27bdfff8 addiu sp,sp,-8
400764: afbe0004 sw s8,4(sp)
400768: 03a0f021 move s8,sp
40076c: afc40008 sw a0,8(s8)
400770: 8fc20008 lw v0,8(s8)
400774: 00000000 nop
400778: 10400003 beqz v0,400788 <test+0x28>
40077c: 00000000 nop
400780: 2402162e li v0,5678
400784: afc20008 sw v0,8(s8)
400788: 03c0e821 move sp,s8
40078c: 8fbe0004 lw s8,4(sp)
400790: 27bd0008 addiu sp,sp,8
400794: 03e00008 jr ra
400798: 00000000 nop


The first line is added -8 to sp,
but after a few lines , the code stores word(4bytes) to the stack(sp + 8).
that means it is required some stack allocation before call the function.

Of course we need to understand the difference of psp-gcc and mipsel-linux-uclibc-gcc.

Anyway, thank you for telling me and sorry for this long my not proper English.

Regards,
--------
BouKiCHi

[Ari64]

.macro m_seb dest,src
        sw      t0,-4($sp)
        andi    \dest,\src,0xff
        xori    \dest,0x80
        ori     t0,zero,0x80
        sub     \dest,t0
        lw      t0,-4($sp)
.endm

Exophase is right, this is bad. Try this instead:

 sll dest,src,24
 sra dest,dest,24

or

 andi dest,src,0xff
 xori dest,dest,0x80
 addi dest,dest,0xffffff80

> >At the very least, m_jal need not be used for the branches to internal
subroutines.

if he is saying about PSP version, then he is right.
but not right for a320 and other linux stuff.

Under Linux, what I did was to add to the gcc flags: -Xlinker --section-start -Xlinker .init=0x08000000
Then: mmap(0x7000000, 0x1000000, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS, -1, 0)
(Look at the Makefile and new_dynarec.c in the mupen64plus source.)

[Rodrigo Cardoso]

http://clogging.blog57.fc2.com/blog-entry-132.html

He released a new version