You are not logged in.
Lost Password?

All Posts (ElmerPCFX)




#41
Re: A newer GCC compiler.
Posted on: 2016/3/25 4:24
VB Gamer
Joined 2016/3/13
42 Posts
Long Time User (3 Years)
Quote:
RunnerPack wrote:
I'm only barely "assembly-capable" on the v810, but I'll take a shot at answering these.

Thanks!



Quote:
There really is no "the VirtualBoy SDK" due to a lot of fragmenting, but, TMK, most of the existing code out there avoids direct access to registers except in the necessary setting of hardware ports for control of the peripheral hardware. If you want to make use of these registers for a specific purpose (especially if it means improving memory usage of generated code), I'm sure existing projects could be made compatible quite easily.

Ah ... I'm going by the Nintendo Seminar docs, and the PC-FX SDK docs, and the GCC docs ... all of which follow NEC's V810 Architecture Manual, where R2 is reserved as the "Handler Stack Pointer", and R5 is reserved as the "Text Pointer" (which means the address of the start of the program code).

Now, the PC-FX BIOS and the official SDK libraries (which I'm going to ignore), never actually use either of these registers, they're just wasted.

Newer versions of GCC (well after 2.95, I think) added an option "-app-regs" that lets the compiler use these 2 registers for the code that it generates.

I'd be quite surprised if anyone here is relying on that option.

I have my own ideas of how I'd like to use those registers.

I'd like to move the Frame Pointer to R2 (right next to the Stack Pointer in R3), and I'd like to use R5 to replace the V850's EP register ... and basically gain another 32KB of fast-access variable space, particularly for use as thread-local variables.

This isn't going to cause any problems on the PC-FX ... but I'm curious if it will cause any problems on the VirtualBoy.

If you're programming bare-metal with no BIOS or Nintendo libraries ... then it shouldn't really cause you guys any trouble, either.

As for "memory usage" ... how "cramped" are you guys? Are you using the "optimize-for-space" option and/or the "prolog-function" option?



Quote:
The cartridge ROM has either 1 or 2 (the default) wait-states, selectable in software. The RAM used by the video hardware (the "VIP") has 2-5 waits, depending on what part of the display rendering cycle it's currently in. All other areas have a fixed wait-state of 1.

OK, thanks! I guess that Nintendo went a little cheap on the memory (again).

The PC-FX runs everything from RAM, so I'm more worried about pipeline-stalls than I am about memory access times.

I guess that you guys have different issues, and that the VirtualBoy's memory timing dwarfs the occasional modify-then-read pipeline-stall.

That means that I should definitely keep the frame-pointer "optional" rather than "required" (which is a pity, because it's so darned useful when implemented properly).



Quote:
None of the existing, publicly-available, homebrew VB software uses any Nintendo code, binary or otherwise. I can't speak for what anyone has on their personal PCs, though.

Excellent, you've got a completely clean-and-legal toolkit, and that means that you've got the source-code to make any changes if you use the new 2010 ABI, or whatever I come up with (if it's an improvement).
Top

Topic | Forum


#42
A newer GCC compiler.
Posted on: 2016/3/24 23:20
VB Gamer
Joined 2016/3/13
42 Posts
Long Time User (3 Years)
Hi, I'm new to the site ... until yesterday I didn't even know that anyone had updated the GCC V810 patches passed the original GCC 2.95 patches that were (AFAIK) done by a bunch of Japanese guys in 2000 (for the PC-FX, I believe).

Anyway ... I'm trying to "open-up" the PC-FX for development and have done my own update of the old 2.95 patches to binutils 2.23.2 and GCC 4.7.4, in order to get a "modern" C compiler with C99 capability, and with nearly-all of C11.

It occurs to me that you guys over here with a love for the VirtualBoy may be interested in the work that I've done, and that you might be a larger group to provide a test-bed, rather than the PC-FX community, where I'm pretty-much the only assembler-capable developer.


I've had a quick "chat" with KR155E, and with his help, I've found the following threads ...

"experimental gcc4 patches"
http://www.planetvb.com/modules/newbb/viewtopic.php?topic_id=3883

"gccVB optimization options and assembly code"
http://www.planetvb.com/modules/newbb/viewtopic.php?topic_id=5055

"Compiling gccvb 4.4.2 under Cygwin"
http://www.planetvb.com/modules/newbb/viewtopic.php?topic_id=5328


From what-I-can-see, I don't think that my patches are experiencing any of the problems that have been reported in those threads, except for the "movhi optimization" issue ... which isn't really an "issue" as such, it's because the compiler doesn't know where the labels are going to resolve to, so it has to generate full 32-bit loads.

That may be something that the linker can resolve with "whole-program-optimization", but I've not been brave-enough to even try to compile the toolchain with that feature enabled.


The new patches are built with mingw64/msys2, and not cygwin, so they're Windows-native programs.

In trying to clean-up the code so that I could understand (and debug) what was going on, I removed a bunch of pointless options that don't make any sense to the PC-FX (or VirtualBoy), such as the long-call, long-jump, GHS, and app-regs. Hopefully nobody here cares about those.

I have a version that uses the old GCC 2.95 ABI (with the 16-bytes of stack reserved for r6-r9), and I just completed the transition to the new GCC ABI from 2010 that removes that redundant stack space.

My next task is to change the ABI even more so that I can get useful stack-frames and actually implement a working backtrace function for debugging.

So ... I have a couple of technical questions for the assembly-capable developers here.

I've not seen the VirtualBoy SDK (and don't particularly want to wade through it) ... but are the V810's registers R2 and R5 actually used in whatever VirtualBoy libraries you guys use?

Does the VirtualBoy have single-cycle RAM, or does it have wait-states that slow down RAM access?

Are you using any Nintendo binary-only libraries, or can you re-assemble/re-compile whatever libraries/engines that you're using?
Top

Topic | Forum