Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #21  
Old 24th January 2015, 02:14 PM
Tarek701's Avatar
Tarek701 Tarek701 is offline
Member
 
Join Date: Mar 2009
Posts: 58
Default

Mhh, I'm asking right now how the rsp branch commands work. Do they also jump to addresses if the condition is true?

For example, IDA Pro shows the instruction VEQ (if vectors are equal) as:



It doesn't seem to jump to an address or is this just yet again some wrong disassembly of IDA? Or is this somehow done through mfc2?

EDIT:
Also, what do VRCP, VRCPL, VRCPH, VMOV, RSQ, VRSQL, VRSQH do? IDA Pro doesn't disassemble those and just show them as cop2. I don't know how it would look like in syntax.
__________________
==========================
Familiar with MIPS r4300i ASM, Basic stuff in C.

Last edited by Tarek701; 24th January 2015 at 02:25 PM.
Reply With Quote
  #22  
Old 24th January 2015, 04:11 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

bgez is the branch command there.
I'm not really a R4300 person, but I think if I were to check, it means branch if ($t0 >= 0).

VEQ is just for setting carry flags in one of the CP2 control registers. Doesn't branch.

As for
Quote:
Originally Posted by Tarek701
Also, what do VRCP, VRCPL, VRCPH, VMOV, RSQ, VRSQL, VRSQH do? IDA Pro doesn't disassemble those and just show them as cop2. I don't know how it would look like in syntax.
, those are invalid opcode mnemonics on the SGI O2 MSP I think...they are valid on the RSP, but SGI used those opcode positions for something else after doing the N64 RCP.

But back when they did the RSP, those opcodes were scalar element writes to a vector register. They're all under the divide class of instruction (using an 11-bit-precise FP look-up table to indirectly "compute" the division): RCP means reciprocal (1 / x), RSQ means reciprocal of the square root (1 / sqrt(x), or sqrt(1 / x)), and VMOV just moves it without doing any division.
Reply With Quote
  #23  
Old 7th February 2015, 09:53 AM
Tarek701's Avatar
Tarek701 Tarek701 is offline
Member
 
Join Date: Mar 2009
Posts: 58
Default

Just asking:
Do MFC2 and MTC2 allow scalar modes? I've been trying to figure this out, but it doesn't seem like that. Well, you know it is that logical thought you get first: Why shouldn't you be able to move vector elements from/to the target?

The disassembler does show it always as [0] implying that it's just working register-specific (aka you can just move the whole register or nothing).



EDIT:
I'm also wondering about this:


I could swear that some RSP doc said that DMTC2 doesn't exist. Maybe I was wrong, but well. It stands here. I'm kinda confused with that "7".
__________________
==========================
Familiar with MIPS r4300i ASM, Basic stuff in C.

Last edited by Tarek701; 7th February 2015 at 10:02 AM.
Reply With Quote
  #24  
Old 7th February 2015, 02:40 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

MFC2 is not a vector operation so it doesn't accept a vector operand specifier. It does however let you move one of a vector register's 16-bit elements, starting at the byte offset *(VR[vd] + element), where element is a 4-bit integer. So it's from 0 to 15, just a regular value. 0 would mean move the first 16 bits, but not the whole 128 bits. It's actually identical to SSV from under SWC2, except that it doesn't interface with DMEM and just stores it to a scalar GPR instead.

And yeah there is no such thing as DMTC2 on rsp. I doubt that IDA Pro necessarily has to conform to the N64's RSP; it could be later SGI revisions where they didn't remove so much 64-bit stuff.
Reply With Quote
  #25  
Old 7th February 2015, 03:54 PM
Tarek701's Avatar
Tarek701 Tarek701 is offline
Member
 
Join Date: Mar 2009
Posts: 58
Default

Quote:
Originally Posted by HatCat View Post
MFC2 is not a vector operation so it doesn't accept a vector operand specifier. It does however let you move one of a vector register's 16-bit elements, starting at the byte offset *(VR[vd] + element), where element is a 4-bit integer. So it's from 0 to 15, just a regular value. 0 would mean move the first 16 bits, but not the whole 128 bits. It's actually identical to SSV from under SWC2, except that it doesn't interface with DMEM and just stores it to a scalar GPR instead.

And yeah there is no such thing as DMTC2 on rsp. I doubt that IDA Pro necessarily has to conform to the N64's RSP; it could be later SGI revisions where they didn't remove so much 64-bit stuff.
Ah, I see. So, MFC2 doesn't let you (for example) move v12[4] to a GPU register? As far as I know that four 0000's after cop2 encoding are for specifying whether it's a mfc or mtc. (like FPU's MFC1) So I can just move the whole v12?
__________________
==========================
Familiar with MIPS r4300i ASM, Basic stuff in C.

Last edited by Tarek701; 7th February 2015 at 04:02 PM.
Reply With Quote
  #26  
Old 7th February 2015, 04:10 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

Code:
   0001 0203 0405 0607 0809 0A0B 0C0D 0E0F
127                                      0
MFC2 $at, $v12[4]

would move

SR[1] = 0x0405
Reply With Quote
  #27  
Old 7th February 2015, 04:16 PM
Tarek701's Avatar
Tarek701 Tarek701 is offline
Member
 
Join Date: Mar 2009
Posts: 58
Default

Quote:
Originally Posted by HatCat View Post
Code:
   0001 0203 0405 0607 0809 0A0B 0C0D 0E0F
127                                      0
MFC2 $at, $v12[4]

would move

SR[1] = 0x0405
ah, I get it now. Well. Now how would the encoding look like for this (for the whole instruction):



010010 00100 01110 01010 00000000000
<cop2> <mfc> <t0> <v27> <nothing?>

So, if I want now MFC $t0, $v27[4] how would this be encoded above? Would it make use of those last zero's or does it have something to do with the "mfc" specifier thing?
__________________
==========================
Familiar with MIPS r4300i ASM, Basic stuff in C.
Reply With Quote
  #28  
Old 7th February 2015, 04:46 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

Quote:
Originally Posted by Tarek701 View Post
010010 00100 01110 01010 00000000000
<cop2> <mfc> <t0> <v27> <nothing?>
That's MTC2. MFC is rs = 00000_2, not 00100_2.

And v27 should be 27 in binary...which if my math works out, 16 + 8 + 2 + 1 so 11011_2, not 01010_2.

And there is no $t0 register on the RSP. $t0 is a MIPS register name for the R4300 CPU that the N64 uses...but the RCP uses a R4000-based CPU, with no such reservations on the registers' purposes (except that register 0 is always equal 0, and the "$ra" name refers to GPR $31). Furthermore, T0 on the N64 CPU corresponds to register number 16, or 10000_2, so I'm not sure where 01110_2 came from.

So it would look more like:
Code:
MFC2    $16, $v27[4] # r16 called "T0" on original MIPS architecture

010010 00000 10000 11011 0100- ------
The function bits, inst & 0x0000003F, and the LSB of MIPS.R.sa (all colored gray there) mean nothing and can all be set to 0 by standard assemblers. The function bits only matter if the MSB of the rs bit-field specifier is set, or (rs >= 10000_2).
Reply With Quote
  #29  
Old 7th February 2015, 04:59 PM
Tarek701's Avatar
Tarek701 Tarek701 is offline
Member
 
Join Date: Mar 2009
Posts: 58
Default

Quote:
Originally Posted by HatCat View Post
That's MTC2. MFC is rs = 00000_2, not 00100_2.

And v27 should be 27 in binary...which if my math works out, 16 + 8 + 2 + 1 so 11011_2, not 01010_2.

And there is no $t0 register on the RSP. $t0 is a MIPS register name for the R4300 CPU that the N64 uses...but the RCP uses a R4000-based CPU, with no such reservations on the registers' purposes (except that register 0 is always equal 0, and the "$ra" name refers to GPR $31). Furthermore, T0 on the N64 CPU corresponds to register number 16, or 10000_2, so I'm not sure where 01110_2 came from.

So it would look more like:
Code:
MFC2    $16, $v27[4] # r16 called "T0" on original MIPS architecture

010010 00000 10000 11011 0100- ------
The function bits, inst & 0x0000003F, and the LSB of MIPS.R.sa (all colored gray there) mean nothing and can all be set to 0 by standard assemblers. The function bits only matter if the MSB of the rs bit-field specifier is set, or (rs >= 10000_2).
Thank you. Yeah, probably I gave you the wrong encoding (probably the one above or below mfc2, mtc2.) But I get now what you mean. And I thought before the last zero's were just there for fun and to get to 32-bits. Lel. Btw, cause I gave you the false encoding it's actually T6 (01110 on GPU, while T0 is 01000) so yeah, stupid me.



That's what I get using your encoding. So, yeah. IDA Pro doesn't do it right, unfortunately.

EDIT:
Ye, IDA Pro doesn't knows about the element specifying thing. lol

__________________
==========================
Familiar with MIPS r4300i ASM, Basic stuff in C.

Last edited by Tarek701; 7th February 2015 at 05:09 PM.
Reply With Quote
  #30  
Old 7th February 2015, 06:27 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

That is weird.

Try sa 16 instead of 8 then ? (i.e. element is 8 instead of 4)

Code:
MFC2    $16, $v27[8] # r16 called "T0" on original MIPS architecture

010010 00000 10000 11011 1000- ------
Maybe it's complaining that the vector offset isn't legally aligned on an appropriate boundary, and it's trying to move 32 bits not 16 bits.
Reply With Quote
Reply

Tags
assembler, mips, r4300i, sm64, tarek701

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 06:01 PM.


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