So, I have my second-hand HP vx2000 (Single-CPU Itanium2 workstation) running in my room. (OK, this itself is a mistake – it’ll be moved into the home office once I get sick of the added head in my room).
For some bizare reason, I seem to have come up with the idea that trying to port Plan9 to it would be a good idea.
I’ve started studying the architecture and standard ABI documentation and I’m still trying to get my head around little details, but the whole thing seems pretty doable if I beat kencc into shape first.
The standard ABI register usage suggests a mixture of caller-save/callee-save conventions (some of the global registers are available as caller-save scratch) – this should only require minimal changes to kencc as it’s a case of teaching kencc to work out how many extra registers it thinks it needs for any given proc for optimal results, and allocating them dynamically via the appropriate mechanism, and then ignoring their save/restore on call/return. That itself shouldn’t hurt kencc much (unlike on sparc32, etc, where you need to work almost exclusively in the callee-save model to get best results if you want to use register windows, and that’s fairly contrary to how kencc thinks and allocates registers), but will make context switching and debugging a bit more complicated.
Alternatively, we could just ignore register spill-fill and try to cram ourselves into the scratch registers only. This would probably sit well with most plan9 developers.
Last (and equally insane option) is to meet minimum requirements for spill/fill (so EFI calls that allocate registers won’t kill us), but allocate all the registers and treat them as caller-save globals
This will make context saves even more expensive (saving 128 64-bit registers WILL suck), but is simple.
Anyway, this isn’t the really hard bit – as far as I can tell, the hard bit is fixing the 9 assembler/loader to produce good ia64 machine code and pick sensible optimisations.