#1  
Old 6th May 2015, 07:34 AM
deadcast64 deadcast64 is offline
Junior Member
 
Join Date: Mar 2015
Posts: 7
Question Writing New RSP Code

I've been really wanting to write a new RSP program to learn more about the internals of the N64. So knowing that the RSP is based off of the MIPS R4000 processor, I naively went and configured a new gcc/binutils/newlib toolchain that targeted the R4000. I soon realized after trying to compile some new assembly using the "VADD" opcode, I received "Error: opcode not supported on this processor."

So am I crazy or is it possible to configure a new modern assembler for the RSP without using the ASM64 compiler floating around? Did I perhaps miss some critical configuration in my toolchain setup? I've tried using the MIPS 3/4 opcode compile flags but it still won't recognize the vector operation. I think all of this stuff is way over my head.

I'll see if anyone knows on the #n64dev channel as well.

Thanks!
Reply With Quote
  #2  
Old 6th May 2015, 03:50 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,245
Default

That should be an assembler error, but the compiler by itself if you could get GCC to either 1) auto-vectorize to generate the VADD instruction, 2) support inline asm, 3) write an intrinsics API and header of static functions that gives C code direct access to the VADD instruction and other vector op-codes from intrinsic functions, similar to Intel's <emmintrin.h>, or 4) never mind supporting within GCC but compile .asm or .s files separately from the .c files and run them directly through the assembler, then it shouldn't matter within the compiler's side.

But for the assembler itself you may have to implement the support for sp ops yourself, unless one already exists (probably does).
Reply With Quote
  #3  
Old 6th May 2015, 03:57 PM
OldGnashburg's Avatar
OldGnashburg OldGnashburg is offline
Project Supporter
Member
 
Join Date: Jul 2013
Location: Canada; a place with free universal healthcare and f*ckload of oil and Uranium.
Posts: 70
Default

Not a programmer, but isn't the isn't it based off VR4300i? Not R4000?
__________________
Gnash, Gnash, Gnash...
Reply With Quote
  #4  
Old 6th May 2015, 04:21 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,245
Default

Well, there is no VR4300i.

There's an MIPS R4000 series of micro-processors which is the line of instruction set architecture implemented in the RSP's ISA, with much subsetting and supersetting.

The main N64 CPU is another model entirely, the R4300i, modified by NEC to become known also as "VR4300". Most people just say r4k or r4300 or r4300i with the 'i' at the end, but I remember cen switching between saying R4300i to VR4300 around the same time I started saying it.

Two different CPUs you're thinking of: The master CPU and the slave, multimedia-processing CPU within the RCP.
Reply With Quote
  #5  
Old 6th May 2015, 04:34 PM
OldGnashburg's Avatar
OldGnashburg OldGnashburg is offline
Project Supporter
Member
 
Join Date: Jul 2013
Location: Canada; a place with free universal healthcare and f*ckload of oil and Uranium.
Posts: 70
Default

Ah, my mistake. Like I said, I'm not a programmer, I know the basic basics of hardware, but not enough to know about their design and whatnot.
__________________
Gnash, Gnash, Gnash...
Reply With Quote
  #6  
Old 6th May 2015, 06:42 PM
deadcast64 deadcast64 is offline
Junior Member
 
Join Date: Mar 2015
Posts: 7
Default

Quote:
Originally Posted by HatCat View Post
That should be an assembler error, but the compiler by itself if you could get GCC to either 1) auto-vectorize to generate the VADD instruction, 2) support inline asm, 3) write an intrinsics API and header of static functions that gives C code direct access to the VADD instruction and other vector op-codes from intrinsic functions, similar to Intel's <emmintrin.h>, or 4) never mind supporting within GCC but compile .asm or .s files separately from the .c files and run them directly through the assembler, then it shouldn't matter within the compiler's side.

But for the assembler itself you may have to implement the support for sp ops yourself, unless one already exists (probably does).
Thanks! Really helpful info. I was actually just going to compile the assembly along side of the .c files but being able to program in c for everything would be nice. I think I could do inline but I'll just try the .S file route first. I didn't know about the Intel stuff. Pretty cool.

So is the VADD op just a wrapper for other MIPs opcodes that are called? Like really it's just using a plain old ADD and other basic codes under the hood?
Reply With Quote
  #7  
Old 6th May 2015, 06:55 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,245
Default

vadd is a vector operation but not a pseudo-instruction.

It cannot wrap directly around MIPS scalar `ADD` op. The way I remember it it adds two vectors of 8 x 16-bit elements and stores the saturated sum (no wraparound, clamped to a minimum of -32768 and a maximum of +32767) to a third 8 x 16-bit vector, excluding the work of maintaining some carry/borrow flags. I can't remember fully, as it's been a while since I wrote that part of my RSP for readability instead of speed and accuracy.

So if you ignore some state machine principals with preserving flags and the accumulator:
Code:
extern int16_t VR[32][8];

void vadd(int vd, int vs, int vt)
{
    static int32_t acc[8];
    register int i;

    for (i = 0; i < 8; i++)
        acc[i] = VR[vs][i] + VR[vt][i];
    for (i = 0; i < 8; i++)
        VR[vd][i] = pack_signed(acc[i]);
}
Reply With Quote
  #8  
Old 6th May 2015, 08:57 PM
deadcast64 deadcast64 is offline
Junior Member
 
Join Date: Mar 2015
Posts: 7
Default

Quote:
Originally Posted by HatCat View Post
vadd is a vector operation but not a pseudo-instruction.

It cannot wrap directly around MIPS scalar `ADD` op. The way I remember it it adds two vectors of 8 x 16-bit elements and stores the saturated sum (no wraparound, clamped to a minimum of -32768 and a maximum of +32767) to a third 8 x 16-bit vector, excluding the work of maintaining some carry/borrow flags. I can't remember fully, as it's been a while since I wrote that part of my RSP for readability instead of speed and accuracy.

So if you ignore some state machine principals with preserving flags and the accumulator:
Code:
extern int16_t VR[32][8];

void vadd(int vd, int vs, int vt)
{
    static int32_t acc[8];
    register int i;

    for (i = 0; i < 8; i++)
        acc[i] = VR[vs][i] + VR[vt][i];
    for (i = 0; i < 8; i++)
        VR[vd][i] = pack_signed(acc[i]);
}
Ahh very cool. Thanks for the example! To be frank, I'm still not quite sure what a "vector" is. lol Just like a float? I'm coming from the land of C#, Ruby and JavaScript.

Also I was just talking to krom and ARM9 and they pointed me to some really cool stuff of theirs. They've already written macros for the special ops so I could just translate those into a gcc assembly macro. Still got my work cut out for me though since I'm still a little unsure of how to load stuff onto the RSP's IMEM/DMEM. ARM9 made a macro for that though so I'll just mess around and wait for the cen64 to finally recognize something I'm doing.
Reply With Quote
  #9  
Old 6th May 2015, 10:47 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,245
Default

"Vector" is the antonym of "scalar". Physically they're open to interpretation, but with media signal processing in computer hardware (graphics, audio, video...) it concerns vector units. A vector unit is a unit of the signal processor (in this case, the RSP) that handles parallel data operations at once per compact, single instructions (see also "Single Instruction, Multiple Data" -- SIMD), much like the basic operation I posted above for VADD.

That is, VADD adds a vector of 8 16-bit integers to another vector of 8 16-bit integers to store 8 packed sums to a destination vector. All of these vectors are vector registers and contain multiple data (as in Physics, vectors have more than one dimension of measurement, sort of, whereas scalars are straightforward). What you know as the general-purpose 32 registers on the MIPS R4000 ISA are actually, on the RSP, the 32 scalar registers, part of the scalar unit (SU), the other half of the RSP.
Reply With Quote
  #10  
Old 8th May 2015, 03:56 AM
deadcast64 deadcast64 is offline
Junior Member
 
Join Date: Mar 2015
Posts: 7
Default

Quote:
Originally Posted by HatCat View Post
"Vector" is the antonym of "scalar". Physically they're open to interpretation, but with media signal processing in computer hardware (graphics, audio, video...) it concerns vector units. A vector unit is a unit of the signal processor (in this case, the RSP) that handles parallel data operations at once per compact, single instructions (see also "Single Instruction, Multiple Data" -- SIMD), much like the basic operation I posted above for VADD.

That is, VADD adds a vector of 8 16-bit integers to another vector of 8 16-bit integers to store 8 packed sums to a destination vector. All of these vectors are vector registers and contain multiple data (as in Physics, vectors have more than one dimension of measurement, sort of, whereas scalars are straightforward). What you know as the general-purpose 32 registers on the MIPS R4000 ISA are actually, on the RSP, the 32 scalar registers, part of the scalar unit (SU), the other half of the RSP.
Ah ok that makes more sense. Thanks for the explanation. I wasn't sure if vector actually meant like an n-dimensional mathematical vector(<x, y, z>) or just some sort of special number.
Reply With Quote
Reply

Tags
assembly, n64, rsp

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 05:11 AM.


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