Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #11  
Old 27th February 2013, 12:08 AM
MarathonMan's Avatar
MarathonMan MarathonMan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2013
Posts: 454
Default

Quote:
Originally Posted by FatCat View Post
I was just looking back at a couple of your posts back on EmuTalk.

This isn't very important (unless you're a perfectionist like me), but I looked back at a couple of the verbosity displays you have in CEN64:
Code:
[RSP]: "Initializing COP0."
[RSP]: "Initializing COP2."
To be clear, it would probably be preferrable to say "CP0 and CP2" instead of "COP0 and COP2", unless you literally are initializing the actual instructions in the opcode matrix or something.

MIPS family revisions documentation always denotes the co-processors as "CPz", where 0 <= z <= 3.

"COP" probably means "coprocessor operation" (they use "CO" in the MIPS32 matrix in updated manuals not applied to the N64), except the "C" in "COP" means "coprocessor" and "OP" means "operation", most likely though I don't know this for sure.

Nobody gives a shit but me.
That's actually a very good point, thanks. Imma commit that in a second. I renamed the 'XBUS' plugin to 'BUS' for the same reason this weekend -- apparently the 1GB/s bus that links the RSP and RDP is actually an XBUS, while the bus connecting all the interfaces and controllers is just a generic bus.

EDIT:
Code:
...@...:~/Projects/cen64$ ./cen64 data/pifrom.bin data/zelda.rom 9
[PIF]: "Initializing PIF."
[ROM]: "Initializing Interface."
[RDRAM]: "Initializing RDRAM."
[RSP]: "Initializing CPU."
[RSP]: "Initializing CP0."
[RSP]: "Initializing CP2."
[VR4300]: "Initializing CPU."
[VR4300]: "Initializing CP0."
[BUS]: "Initializing Bus."
[BUS]: "== Hardware Initialized =="
[BUS]: "Connecting devices."
[ROM]: "Preparing the image."
[ROM]: "Loaded: [THE LEGEND OF ZELDA ]"
[ROM]: "Detected: CIC-NUS-6105."
[CEN64]: "== Booting the Console =="
[VR4300]: "Handling fault: RST"
Gave you cred in the commit log, FWIW.

Last edited by MarathonMan; 27th February 2013 at 12:43 AM.
Reply With Quote
  #12  
Old 27th February 2013, 12:10 AM
MarathonMan's Avatar
MarathonMan MarathonMan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2013
Posts: 454
Default

Quote:
Originally Posted by FatCat View Post
By the way.

Is branch prediction (or even prevention) so important, that you would consider this simplified method of clamping VMULF accumulator results to the destination vector register file:

Code:
; 20   :         VR[vd].s[i] = (VACC[i].W[0] == 0x80008000) ? 0x7FFF : VACC[i].s[MD];
.. inferior to this method?
Code:
; 20   :         VR[vd].s[i] = VACC[i].s[MD] - (VACC[i].W[0] == 0x80008000);
Because if the vector accumulator result was 0x000080008000, then VACC[i].s[MD] is 0x8000, so we subtract 1 (the condition (acc == 0x000080008000)) from the result to effectively produce the 0x7FFF 16-bit signed overflow clamp result.

This is one way to prevent branching altogether but would you say it's worth it based on the clues you have provided me?
I'd take the second method ANY day of the week. Yes, branch prediction is that important -- if what you're doing is only an instruction or two more but saves you from doing a branch, prefer that option every single time.
Reply With Quote
  #13  
Old 18th March 2013, 03:49 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

Thanksfor confirming; I've been doing that everywhere now while I've been offline.
Lots of cleanups and speed-ups to the interpreter method!

You can credit me as Iconoclast or sdfsdfdbreakpointfound, idk
Reply With Quote
  #14  
Old 21st March 2013, 01:30 PM
MarathonMan's Avatar
MarathonMan MarathonMan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2013
Posts: 454
Default

Quote:
Originally Posted by FatCat View Post
Thanksfor confirming; I've been doing that everywhere now while I've been offline.
Lots of cleanups and speed-ups to the interpreter method!

You can credit me as Iconoclast or sdfsdfdbreakpointfound, idk
You're alive.

I refer to you everywhere as Iconoclast.
Reply With Quote
  #15  
Old 21st March 2013, 07:57 PM
squall_leonhart's Avatar
squall_leonhart squall_leonhart is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Mar 2007
Location: Sydney, Australia
Posts: 2,918
Default

i refer to him as the Royal Asshat
__________________

CPU:Intel Xeon x5690 @ 4.2Ghz, Mainboard:Asus Rampage III Extreme, Memory:48GB Corsair Vengeance LP 1600
Video:EVGA Geforce GTX 1080 Founders Edition, NVidia Geforce GTX 1060 Founders Edition
Monitor:ROG PG279Q, BenQ BL2211, Sound:Creative XFI Titanium Fatal1ty Pro
SDD:Crucial MX300 275, Crucial MX300 525, Crucial MX300 1000
HDD:500GB Spinpoint F3, 1TB WD Black, 2TB WD Red, 1TB WD Black
Case:NZXT Phantom 820, PSU:Seasonic X-850, OS:Windows 7 SP1
Reply With Quote
  #16  
Old 21st March 2013, 09:34 PM
ExtremeDude2's Avatar
ExtremeDude2 ExtremeDude2 is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2010
Location: USA
Posts: 3,109
Default

Quote:
Originally Posted by MarathonMan View Post
You're alive.

I refer to you everywhere as Iconoclast.
This ^^
__________________
Quote:
Originally Posted by dsx! View Post
are you american or something
Reply With Quote
  #17  
Old 23rd March 2013, 02:49 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

Quote:
Originally Posted by MarathonMan View Post
You're alive.

I refer to you everywhere as Iconoclast.
Yeah, sorry I'm deprived of Internet I can barely log on for these next few weeks...even now I lack the time to give your helpful ansswers a full reply

But I had to get a minute in and ask this.
I've made a huge number of massive rewrites to the RSP emu,

one of the things I did was use a two-dimensional array of 16-bit shorts (VR[32][8]) to use the proper, big-endian byte order, which allowed me to write 16-bits from odd-indexed byte elements.

I'm using this macro:
Code:
#define VR_S(v, e) (*(short *)((unsigned char *)(*(VR + v)) + e))
so if element is odd or unaligned I can still write contiguous bits in a single hit!

but how do I index bybyte using pointer rewrites of a 2-D array?

I tried..
Code:
#define VR_B(v, e) (*(unsigned char *)((unsigned char *)(*(VR + v)) + e))
+ 4000 other ways of typing it haven't gotten it to work yet

I suckw ith pointers any alternative strategic ways to get the job done?
Reply With Quote
  #18  
Old 23rd March 2013, 02:39 PM
MarathonMan's Avatar
MarathonMan MarathonMan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2013
Posts: 454
Default

Oh dear heavens. Don't do that. At that rate, you're going to toss aliasing rules out the window.

I'm not sure I fully understand what you're trying to do (?), but I'd highly suggest writing a quick inline function for something like:
Code:
static inline char VR_B(unsigned v, unsigned e) {
   short *slice = VR[v];
   char byte = memcpy(&byte, (char*) slice + e, sizeof(byte));
   return byte;
}
Were you trying to do this??
Code:
#define VR_B(v,e) (((char*) VR[v])[e])

Last edited by MarathonMan; 23rd March 2013 at 02:47 PM.
Reply With Quote
  #19  
Old 23rd March 2013, 07:43 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

Why should I have to write an inline function?

`inline` isn't even an ANSI standard is it?

Why can't a macro function such as the syntax I laid out suffice?
`#define function(params) blah...`

Code:
#define VR_S(v, e) (*(short *)((unsigned char *)(*(VR + v)) + e))
As I said this worked perfectly, it even compiled to the same size assembly code as when I wrote:
VR[vd][element] = data;

So it is small and works perfectly what is there to worry about really?

I'll have to read up more about this "aliasing" matter sometime when I have enough time,

Quote:
Originally Posted by MarathonMan View Post
Were you trying to do this??
Code:
#define VR_B(v,e) (((char*) VR[v])[e])
I was trying, to write a working equivalent to the above macro, except for fetching an 8-bit byte from a pointer to pointer to 16-bit short (short VR[32][8]).

I tried the code you just put there in the macro; that didn't work either.
It gives me one of the common pink/messed up screens in RE2 showing it didn't work, as compared to the old, working but way slower byte access method I am using for LBV

(if element is odd)
load lower byte of VR[v][e] 0x00FF
else if even
load upper byte 0xFF00

As I said the addressing is big endian,

why is it so much h arder to do it with bytes than with halfwords
Reply With Quote
  #20  
Old 23rd March 2013, 08:21 PM
MarathonMan's Avatar
MarathonMan MarathonMan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2013
Posts: 454
Default

Ahhh, I didn't know that you were trying to stick to ANSI; I thought you were just using MSVCxx. C99 has inline. I was just trying to say that you should break it up somehow so it's more legible.

Basically, the aliasing rule says that you can't arbitrary cast from one type to another and then go and reference it later. char * and void * are the exceptions to that rule.

Are you sure you're not getting the endian-ness mixed up somewhere along the way?
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 10:52 AM.


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