[Info-vax] Three boot camp sessions on YouTube

[John Reagan]

On Thursday, October 13, 2016 at 5:30:17 AM UTC-4, Johnny Billquist wrote:
> On 2016-10-12 16:21, John Reagan wrote:
> > On Wednesday, October 12, 2016 at 7:04:27 AM UTC-4, Neil Rieck wrote:
> >> For me, the big difference between Alpha and Itanium in those videos was the register count (32 vs. 128).  Having 128 registers may have seemed like a good idea when they were designing that chip, but we all know that an OS is going to require some/all those registers to be periodically saved then restored (well, not all on every interrupt). I wonder if Intel would have implemented 128 had they known that dynamic memory technology would keep improving as it has.
> >>
> >> So with the shift back to x86, the maximum number of registers appears to be moving to a more manageable number.
> >>
> >> Neil Rieck
> >> Waterloo, Ontario, Canada.
> >> http://www3.sympatico.ca/n.rieck/
> >
> > And now the compilers have to put many more variables on the stack and do memory reads/writes all the time.  Yes, you had to save/restore some of the register stack on interrupts, mode changes, context swaps, etc. but if you count the memory operations saved from not keeping your variables on the stack, I think it might come out better.
> 
> Don't forget that if you have lots of variables in registers, you need 
> to save/restore much more on each call as well. It is, as always, a 
> tradeoff.
> 
> Even more fun with things like register windows, which you have on 
> SPARC. Looks pretty nice to start with, since you move your register 
> window when calling, but then you realize you need to keep track, and 
> when you run out of space in the full register space, the window becomes 
> a burden, and you need to dump a lot of registers in order to clear 
> things up and get running again, meaning it becomes even more complex, 
> and more code to be executed all over the place.
> Register windows never became popular.
> 

Like SPARC, Itanium shifts the registers in the underlying register file.  Only registers r0-r31 are shared from frame to frame.  By convention, just r4-r7 are preserved across the routine call.  Registers r32-n (where 'n' is based on the 'alloc' instruction) are shifted and essentially preserved from frame to frame by the architecture.  And just like on SPARC, once that underlying frame is full, the register stack engine has to offload registers to actual memory.  The theory was the the stack engine spill/fill was asynchronous but it never worked out that way.  And yes, many events caused the whole thing to be flushed (including by the debugger just so it could see those registers).