It's a set of register settings. The code in the game looks like a bunch of function calls; the stuff the emulator has to deal with is a bunch of opcodes in the FIFO. There's no interpretation per se in the shader - it's not like a pixel shader or a vertex shader, with some kind of bytecode type of affair. It's more like the NV_register_combiners GL extension (http://developer.download.nvidia.com/opengl/specs/GL_NV_regi...).
From a software perspective, there is a solid cut of between "not-shaders" and "shaders". DirectX 7 compatible GPUs don't have "shader" and DirectX 8 compatible GPUs do have "shaders", even if these "shaders" are primitive and only support a maximum of 8 instructions.
But from a hardware perspective, there is no solid cut off between "non-shaders" and "shaders".
Because DirectX 8 era Shaders are just slightly more capable register combiners, with a swanky new shader based programming interface. Oh, and those 8 instructions were shoved into registers, just like on the gamecube.
In some ways, The gamecube's GPU is actually more capable than other DirectX 8 era GPUs (it can support upto 16 instructions), so It's my position that if you consider DirectX 8 gpus to have proper pixel shaders, then you should consider the gamecube has having pixel shdaers too, just with an older clunky programming interface.
The various parts of the instruction (aka register combiner stage) might be split over various registers, but the gamecube GPU executes them as whole instructions in series, just like a shader core. Our Ubershader acts like a proper interpreter, interpreting the raw data out of these registers cycle by cycle as machine code, just like the real hardware.
what does the code look like?