Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #11  
Old 15th February 2013, 10:33 PM
MarathonMan's Avatar
MarathonMan MarathonMan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2013
Posts: 454
Default

Excellent work!

This is the one game that I'm really shooting for (a childhood favorite, to say the least). Looks like the game is very liberal in its use of LWC2/SWC2 opcodes, for which my memcpy optimization is going to pay itself off twelve times over.

You don't track the NOPs separately? IIRC, SLL by zero is a NOP, but that might be exclusive to the VR4300. Other than that, looks similar to before... lots of VMADH/VMADN, a good amount of VADDs, etc.
Reply With Quote
  #12  
Old 15th February 2013, 11:24 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Quote:
Originally Posted by MarathonMan View Post
Excellent work!

This is the one game that I'm really shooting for (a childhood favorite, to say the least). Looks like the game is very liberal in its use of LWC2/SWC2 opcodes, for which my memcpy optimization is going to pay itself off twelve times over.
That's true.
Thinking about it, VMADH gets executed 57 million times, but SDV alone, just by its self, is already used half as frequently ... maybe I should be leaving the standard vector ops soon so I can optimized ?WC2.

Quote:
Originally Posted by MarathonMan View Post
You don't track the NOPs separately? IIRC, SLL by zero is a NOP, but that might be exclusive to the VR4300. Other than that, looks similar to before... lots of VMADH/VMADN, a good amount of VADDs, etc.
According to the standard MIPS manual (at least the diagrams), all 32 bits of the fetched inst must be zeroes for it to be a NOP, but that doesn't mean I know this for sure.

I don't really set aside counts for NOP because I am currently emulating it as a SLL $0, $0, 0, so my RSP emulator handles both SLL and NOP the exact same way. I am not sure if I'm supposed to treat the NOP pseudo-opcode as its own instruction and modify the cycle count or what, but until I get more experienced with timing and cycles, I equalize their execution times for more predictable results.

My iterations log generator lays out everything in the order of the standard opcode matrix.
Blank lines, for example:
Code:
COP0    blah times
        1
COP2    sfdsddf example, times
Means that 1 reserved instruction (COP1) was found in the output (due to my buggy fread file output use of the CRT, or maybe it's M$' fault IDK man).

It helps me guarantee that every single thing in the binary output of all the opcode counts is displayed to me and that I miss nothing.
Since NOP doesn't really have its own position into the opcode table I never really thought of a creative and simple way to implement it.
Reply With Quote
  #13  
Old 22nd June 2015, 02:23 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Never occurred to me but I have released finally the utility I have used in this thread to count the RSP opcode iterations.
The relevant file is countops.c from under .git /rsplog/ which will by itself compile to the executable.

The only thing everyone needs to do to use it is modify some RSP plugin or another to write 4 bytes to a file every time the interpreter CPU fetches an instruction; that way the utility will be able to count all the opcodes of each type countered based on that file. (It will be a very big binary file.)
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 04:00 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.