This is the mail archive of the gdb@sourceware.cygnus.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]

Re: MMX: Messy Multimedia eXtensions



Here are my $0.02 on this:

> - Assign them register numbers separate from the FP stack registers'.
> - Assign them the same numbers as the FP stack registers, and treat them as
>   an alternative way of looking at the FP registers' mantissas.
> The first approach has some problems

Right.  If we do NOT treat the FP and MMX registers as the same
registers, we are in for a lot of trouble.  the only sane way is to
treat them as different views of the same register set.

> The problem is, we're using the same register number for %mm0 and
> %st(0), but %mm0 doesn't really correspond to %st(0).  It depends on
> the value of the FPU TOS register.

Yes, this is not right.  $mm0 should correspond to R0, not to $st0.
However, I don't think it is wise to rely on the program's code to
play by the rules (which effectively guarantee that $mm0 corresponds
to $st0).  Some clever programmer out there is bound to produce code
that uses FP instructions on data left from MMX instructions without
issuing EMMS in between.  GDB should not be confused by such code.

But why is this a problem?  Can't we make the correspondence be
dynamically computed at run time, using the current TOS?  If not, why
not?

One further thought about MMX-related issues:

 * I think we need a function to detect at run time whether MMX (and
   SSE, for that matter) are supported.  The fact that a given
   platform supports these extensions *in principle* does not mean
   that the particular target I'm debugging now does.  If MMX is not
   supported, GDB should not allow to look at the MMX registers.

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