An experiment in optimisation

[PSmonkey]

Well i'm bored and to make my lunch hour more productive, i've desided to mock around with m64 for kicks. Mostly just compiling, seeing the asm output on the devkit and then rewrite the code in mips asm.

To get things out first. I have no plans on releasing this due to legal issues and etc. I also ask all info remain here only. I don't exspect people to fully understand this, this is why I am only posting this here since it's a private forum.

Now lets begin.

--------------------------------------------------------
- Odd issue with Mips? -
I found a strange issue today when compiling code.

*l_Ptr += 3;

This generates 5 instructions. Why is it odd? This is what it does in assembly

LoadWord Reg0, PtrAddr (Store Ptr Addr in reg0)
LoadWorld Reg0, Reg0 (Store value at addr PtrAddr in Reg0)
Add Immedate Reg0, +3 (R0 = R0 + 3)
LoadWord Reg1, PtrAddr (Store Ptr Addr in reg1)
StoreWord Reg0, Reg1 (Write Reg0 at addr PtrAddr in Reg1)

So, Why does the compiler (SN Systems) reload the pointer address? This is a little puzzling and i'm not sure why.

I'm finding it difficult to find a C solution to solve this. Even if I write asm to do the 2nd,3rd & 5th instruction, the compiler will force 1st & 4th instruction in. =/

So my only solution is to manualy do it in 4 instructions which is not bad but not a great idea either (since I have to keep track of where the ptr is in the stack).

- Pointers kept localy on the Stack -
I learned another interesting thing today. While quite obvious, it's much faster to keep a local pointer to an object on the stack then accessing an object in memory. Why? Well fewer instructions (it takes 2 instructions to load a value from a memory address vs 1 instruction if the object is on the local stack). To add to that *l_pVar is far fewer instructions then g_Regs.m_pVar since it has to check where g_Regs is located and from there get to m_pVar.

=/

- Whats my Goal? -
Really it's to better my understanding of how code is converted into assembly. It's also far more entertaining then the stuff i'm doing during work (huds, bug fixing, and memory cards :P).

While I still don't plan to do a recompiler, I would like to see m64's interpreter become engulfed in mips asm to squeeze much more out of it.

- Double -> Float
Next or comming agenda? Trying to see if it's posible to run n64 entirely in 32bits. The biggest hurdle seems to be double instructions. I experimented with this before in M64 and I could run most cpu instructions in 32bit but when it came to cop1.d (double floating point instructions), it would just fall apart. I think now with a hw debugger I could posibly find a solution to this.

This information (if it works well) could be an interesting thing to implement back into daedalus as it does seem to slow down alot durring heavy use of cop1.d instructions (like mario64's big 3d head in the title screen).


--------------------------------------------------------

That is all for now. Again keep comments about this here. I would like to keep digital notes here that might be of some use in the future (I tend to loose paper notes alot).

[DPyro]

Been a long time since I've looked at this forum. Just wondering, are you actually trying to improve M64 to play more games/run faster, or is this just mucking about with the code?

[PSmonkey]

Code mucking about. I actualy got bored of it after a week since it was not making a big difference and the code base was a little messy (m64 is quite clean but still it's an older style of coding to me).

I'm still just more tempted to try again and write something from scrach. Sadly I don't have the time since as of later this week I move on to a new project (current game is done and off to sony, now time to kick start anotherone due for next year *yeash*).