Re: WIP: Register doco

[Jim Blandy <jimb@redhat.com>]

Andrew Cagney <ac131313@ges.redhat.com> writes:
> > No, I think we need to draw the GDB developer's eye *to* those glossy
> > user-level ISA specs.  :) Figure 8-1 --- the first diagram in the
> > chapter titled "Programming with the X87 FPU" --- has R0 -- R7 right
> > there.  The second diagram, figure 8-2, shows how the TOP field
> > affects the relationship between ST(i) and Ri.  The fact that there is
> > a fixed set of registers accessed as a rotating stack is very much
> > part of the ISA documentation.
> 
> I was talking generally.
> 
> However looking at specific manual set(1)
> (http://developer.intel.com/design/pentium4/manuals), vol1 is the user
> stuff; vol3 is the system stuff.  The GDB developer needs to look
> beyond vol1 and and into vol3.  Vol1 8.1.10 Saving the x87 FPU's State
> with the FXSAVE Instruction, for instance, just points the reader at
> volume 3. In addition, the GDB developer ends up studying kernel
> interfaces and too often (ulgh!) kernel sources.

No, everything I cited was in volume 1, the user's manual set.  The
diagrams explaining the underlying fixed registers and the rotating
names for them are in the "user stuff" manual. 

I'm still trying to get a handle on your intent, though.  In a case
like MIPS III (an ISA with 64-bit registers) running o32 (an ABI which
only uses the lower 32 bits of each register), would you suggest that
printing registers in the usual way should show the full 64 bits of
the register, or only the lower 32 bits?

For the rest, all I'm saying is that the text you've written fails to
draw the distinction you need to make.  The term "hardware registers"
applies equally well to ST(0) and R0.  I've suggested a better way to
make the distinction in the rego document, i.e., by giving examples
showing how real architectures might use the distinction.  If you'd
like me to do that, just let me know.


> > As a sanity check, assuming that SPARC register windows are analogous:
> > the SPARC ISA spec talks about register windows immediately, as well.
> > Figure 2 in the chapter on Registers shows "Three Overlapping Windows
> > and the Eight Global Registers".  (For some reason, that makes me
> > think of Goldilocks and the Three Bears.)
> 
> Just FYI, an example involving the SPARC is on my things todo list for
> frames.  It turns out that the OS for a register-window architecture
> typically flushes all but the inner most window to memory before
> transfering control to GDB.  Consequently the only raw registers that
> GDB sees are those that are innermost.  It is the frame, and not the
> register cache code, that needs to handle this one.

Yeah, since there aren't any underlying protocols I know of that
actually give you all the SPARC register windows directly, the SPARC
would not be a good second example.  Perhaps the IA-64 with its
rotating registers for software-pipelined loops?