Sure.. it was straightforward to track down once you see that a value is in a register but is being collected anyway. I seem to remember the other fun bits were the fact that function pointers were not actually function pointers.. they were pointers into a giant lookup table that contained a struct that contained the actual address of the call. Also, unwinding the stack was so complicated that you could not reasonably do it manually like on nearly any other architecture -- you needed to link in an Intel library to do it. None of these things were giant issues -- it just showed how much of a departure from other prevalent systems it was.
Wow, that does sound like a painful learning curve. Curious, were the function pointer problems inherent to the architecture or the tool/lib you used? Might be worth documenting in case a reader stumbles upon this before going through what you did.
If you want all the nasty details, this post covers it all:
"This also has a side-effect on function pointers. Since function pointers are generally used at some distance from allocation, they might be used in a module with a different gp value. The compiler gets around this by not compiling a function pointer to a single pointer-sized value; it compiles to a pair of pointer-sized values, one representing the address of the first instruction (bundle on IA64) in the function, the other being the correct gp value to use."
Wow. That's a huge mess of stuff to mentally track just for some optimization. To be honest, I'd probably just end up writing a macro-assembler and coding it directly against a C reference implementation just to avoid all the nonsense lol.
