Re: WIP: Register doco

[Jim Blandy <jimb at redhat dot com>]

Andrew Cagney <ac131313@ges.redhat.com> writes:
> > The example of the IA-32's MMX and FP registers is a great example for
> > this.  The MMX registers, MM0--MM7, and the FP registers,
> > ST(0)--ST(7), actually refer to the same set of eight eighty-bit
> > registers, R0--R7.  A reference to the floating-point register ST(i)
> > becomes a reference to R((TOP + i) % 8), where TOP is a three-bit
> > field in the FPU status register.  But a reference to the MMX register
> > MM(i) becomes a reference to the lower 64 bits of R(i) (which would be
> > the mantissa of some ST(i)).
> 
> (In the current code, ST(I) and not R(I) is stored, so we end up with
> MM(I) == regcache(FP0 + (TOP + 1) % 8) :-(   I'm almost ready to dust
> off the patch that does this.)
> 
> Anyway, I think the above example highlights why I see it as important
> to use terms like ``hardware'' or even ``physical''.  Those terms drag
> the GDB developer's eye away from those glossy user level ISA specs,
> and instead focuses their attention on the underlying hardware model
> used to implement the userland ISA. While well above the level of
> flip-flops, it is still a clear step below the ISA that a typical
> native GDB user will be aware of.  (A PPC refers to the ``operating
> environment architecture'').
> 
> For the i387, the programmer spec is all about a register stack, yet
> the underlying hardware uses a block of 8 registers and an index.  It
> is the latter, the lower level hardware details, that the GDB
> developer should focus their attention on when deciding the contents
> of a register cache.

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.

The chapter on MMX also gives the gorey details about how the aliasing
works.  It's not just for gee-whiz value --- you have to know this
stuff in order to write code which does both floating-point and MMX
operations.  Every MMX instruction sets the FPU's TOP field to zero,
for example.

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.)

So in both cases, these underlying structures are explicitly part of
the ISA.  The distinctions can be made clearly without going beyond
the ISA.  We don't need to resort to non-distinctions like "hardware
register" to make our point.

In cases like this one, where we're trying to draw a distinction
(between "cooked" and "raw" registers) whose exact meaning varies from
one architecture to the next, there is no way to really define what
you mean: each person doing a GDB port needs to get the gist of the
distinction, and see how it might help them best describe their
architecture to GDB.  The best way to do that is with a series of
examples showing how it applies to existing, well-known architectures.

I'd be happy to contribute text for those examples, if you agree they
would be useful.  At this point I've dug out the relevant parts of my
IA-32, SPARC, and IA-64 ISA manuals anyway.  :)