Because of the things recently told to me by ex High Voltage Software employees about the compiler setup they used on the Jaguar, I posted the 'paging system' question to a linker expert(Frank Wille, vbcc's vasm assembler and vlink linker author) asking what it would take to implement what HVS described their risc c setup to be like. This was asked before I found the rest of the article that states HVS did indeed know how to run gpu code out of main ram successfully. I don't know how much that will change the landscape of the discussion but here it is with the initial question. So I'm assuming that he is assuming like I did at the time that the compiler was a setup that did NOT execute code out of main ram at all. --[edit: And now it seems that this may have been the case anyway] Here we go:
High Voltage Software wrote:
For Dactyl Joust, we were using an automatic memory paging system which was started with Ruiner. This worked by augmenting function calls to load in each function in 256-byte chunks, as many as needed, and doing address fixups. Rarely called support routines remained in main store, specially tagged to avoid being loaded in. (See above re: running from main RAM and crossing page boundaries. The addresses had to be guaranteed by creating a million sections in the link file. Can you say link file nightmare?) In the end though, C and eventually C++ use became pretty invisible (read easy and efficient) even on the GPU RISC processor.
Now I've always assumed this 'automatic paging system' refers to a linker?
Certainly not. The actual paging must be performed by a runtime system
they had written. The linker can help you to manage all these 256-byte
sections. I guess with "link file" he is refering to the linker script.
I don't quite understand what "augmenting function calls" means, though.
Probably each function was divided into several small sub-functions, where
each of them fits into 256 bytes. Then you have to call all these small
functions instead of a single, big one? But I have no idea how that could
be transparent, when programming in C.
Another possibility would be to connect these 256-byte pages by a jump
to the next page at the end. Jumps to pages which are not already loaded
to the 4K local RAM could point to a paging service routine first, and
then, after the required page is loaded, will be relocated to the correct
destination. A little bit like a mix between virtual memory and a dynamic
linking system. Who knows?
Those of us who knew of this rumor always assumed it was HVS own custom compiler they came up with. But now, one of the old HVS alumni is saying it was Ataris gpu GCC they were using.
Maybe they fixed and enhanced it?
Its just a custom paging system they had to build to get it to work.
Since you're the linker expert, what kind of crazy linker would that have to be to accomplish what he's describing?
I guess the linker could be more or less standard, with a complex linker
script. But they need a specialized compiler to make that paging system
transparent to C.