This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: WIP: Register doco


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

Oh dear, another confusing discussion about the IA-32's FP registers.
While the Intel manuals talk about the registers R0--R7, the ISA
doesn't really expose these.  Both the old fsave and the new fxsave
instructions store ST(I) and not R(I).  Until the introduction of the
Pentium MMX processor the R0--R7 registers really can be considered an
implementation detail, and the fact that the MMX instructions set TOP
to zero makes sure that as far as the MMX registers are concerned,
there still is something like an identity mapping between ST(I) and
R(I).

In other words, I consider the fact that GDB stores ST(I) and not
R(I), the right approach.

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]