View Full Version : 64-bit support

6th August 2010, 03:32 AM
Would pj64 benefit at all from having 64-bit support? Please note, I'm not asking for this as a feature, I just want to know if pj64 would benefit at all from it. I'm building a new pc and want to get it as cheap as possible by putting the power in the right places.

6th August 2010, 04:32 AM
It doesn't benefit from x64 instruction sets, but improved capabilities of x64 processors elsewhere do provide performance improvements.

6th August 2010, 06:15 AM
I'm just curious, why is that? Is the N64's main processor not actually 64 bit?

Thanks for your reply, Squall

6th August 2010, 07:53 AM
the first 64-bit processors are fast enough to run pj64 anyway

6th August 2010, 10:13 AM
Central processing unit

The Nintendo 64's central processing unit (http://en.wikipedia.org/wiki/Central_processing_unit) (CPU) is the NEC (http://en.wikipedia.org/wiki/NEC) VR4300,[20] (http://en.wikipedia.org/wiki/Nintendo_64#cite_note-NECVR4300-19) a cost-reduced derivative of the 64-bit (http://en.wikipedia.org/wiki/64-bit) MIPS Technologies (http://en.wikipedia.org/wiki/MIPS_Technologies) R4300i (http://en.wikipedia.org/wiki/R4300i). Built by NEC on a 0.35 Ám (http://en.wikipedia.org/wiki/Micrometre) process (http://en.wikipedia.org/wiki/Semiconductor_fabrication), the VR4300 is a RISC (http://en.wikipedia.org/wiki/Reduced_Instruction_Set_Computer) 5-stage scalar (http://en.wikipedia.org/wiki/Scalar_processor) in-order execution (http://en.wikipedia.org/wiki/Out-of-order_execution#In-order_processors) processor, with integrated floating point unit (http://en.wikipedia.org/wiki/Floating_point_unit), internal 24 KB (http://en.wikipedia.org/wiki/Kilobyte) direct-mapped[21] (http://en.wikipedia.org/wiki/Nintendo_64#cite_note-20) L1 cache (http://en.wikipedia.org/wiki/CPU_cache) (16KB for instructions, 8KB for data.) The 4.6 million transistors (http://en.wikipedia.org/wiki/Transistor) CPU is cooled passively by an aluminum (http://en.wikipedia.org/wiki/Aluminum) heatspreader that makes contact with a steel (http://en.wikipedia.org/wiki/Steel) heat sink (http://en.wikipedia.org/wiki/Heat_sink) above.[22] (http://en.wikipedia.org/wiki/Nintendo_64#cite_note-21)
Clocked at 93.75 MHz, the N64's VR4300 was the most powerful of the competing consoles of its generation.[23] (http://en.wikipedia.org/wiki/Nintendo_64#cite_note-22) Except for its narrower 32-bit system bus, the VR4300 retained the computational abilities of the more powerful 64-bit MIPS R4300i,[20] (http://en.wikipedia.org/wiki/Nintendo_64#cite_note-NECVR4300-19) though software rarely took advantage of 64-bit data precision (http://en.wikipedia.org/wiki/Precision_%28arithmetic%29) operations. N64 game-titles generally used faster (and more compact) 32-bit data-operations,[24] (http://en.wikipedia.org/wiki/Nintendo_64#cite_note-64_bit-23) as these were sufficient to generate 3D-scene data for the console's RSP (Reality Signal Processor; see below) unit. Though powerful, the CPU was hindered by a 250MB/s bus to the system memory; not only that, but in order to access the RAM (http://en.wikipedia.org/wiki/RAM), the CPU had to go through the RCP (Reality Co-Processor (http://en.wikipedia.org/wiki/Nintendo_64#Reality_Co-Processor)), and could not use DMA (http://en.wikipedia.org/wiki/Direct_Memory_Access) to do so (The RCP could). This problem is further compounded by the RDRAM (http://en.wikipedia.org/wiki/RDRAM)'s very high access latency.
Emulators (http://en.wikipedia.org/wiki/Video_game_console_emulator) such as UltraHLE (http://en.wikipedia.org/wiki/UltraHLE) and Project64 (http://en.wikipedia.org/wiki/Project64) benefit from the scarcity of 64-bit operations in the game's executable-code, as the emulator is generally hosted on a 32-bit machine architecture. These emulators performed most calculations at 32-bit precision, and trapped (http://en.wikipedia.org/wiki/Trap_%28computing%29) the few OS subroutines that actually made use of 64-bit instructions.[24] (http://en.wikipedia.org/wiki/Nintendo_64#cite_note-64_bit-23)

6th August 2010, 10:10 PM
Somewhere else summarized that it's actually two 32-bit processors, rather than strictly one 64-bit processor.

6th August 2010, 11:05 PM
I've actually been given some thought to this for the past few months while I attempt to dissect/understand PJ64.

One of the major downsides of a 32bit cpu is its lack of registers, something the N64 CPU has plenty of.
An x64 CPU has additional registers so in theory there's quite the potential speed boost to gain there.

It's just a theory though and I imagine there would have to be some kind of scheduler to keep all the registers in use.
Ah well, maybe one day I'll get to it heh.

7th August 2010, 12:21 AM
RadeonUser, the usage of SSE allows the use of 8 128bit registers (16 on AMD64).

fwiw though, the original SSE was useless. However i don't see Zilmar alienating a good part of the userbase by moving to SSE2.

The only real benefit of moving to 64bit would be for the Interpreter.

7th August 2010, 07:27 AM
I'm curious to see your data to back that up squall.
I was under the impression no one had made a real push into it due to the lack of interest from the community.

Ultimately my plans will be to create an interpreter that takes advantage of multithreading (using at least two processors and their respective registers) and possibly using directcompute.

It's a learning experience to me more than anything and it'll hopefully be relevant to my dissertation when I get around to it.