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: ST(i) and MMj



> Okay, let's look at read_register_gen (I removed the irrelevant
> clutter):
> 
>     void
>     read_register_gen (regno, myaddr)
> 	 int regno;
> 	 char *myaddr;
>     {
>       if (!register_valid[regno])
> 	target_fetch_registers (regno);
>       memcpy (myaddr, &registers[REGISTER_BYTE (regno)],
> 	      REGISTER_RAW_SIZE (regno));
>     }
> 
> This can be changed like this:
> 
>   1) Define REGISTER_RAW_SIZE to be 8 for MMX registers, and define
>      REGISTER_BYTE so that for MMX registers it goes to the data of
>      the according ST(i) register using the current TOS.
> 
>   2) target_fetch_registers then will actually bring the value of the
>      appropriate ST(i) register when passed a regno of an MMX
>      register.

I thought we had posited that the MMX registers, when stored in
memory, have zero length --- i.e., REGISTER_RAW_SIZE (MM0_REGNO) == 0
--- to avoid overlap problems in loops.


> > I think I'd need to see a very specific explanation of how to do this,
> > showing which functions to change, etc.  Talking about it at a higher
> > level is just getting confusing.
> 
> You are right.  All functions in findvar.c that deal with registers
> will have to be inspected, but just by looking at these functions, it
> seems like a smart enough definition of REGISTER_* macros will do most
> of the work.  We might also need to update register_valid[] for an MMX
> register together with its corresponding ST(i) register, though; this
> might require to introduce a target-dependent function to update
> register_valid[] when a given register REGNO is fetched (but code that
> reads register_valid[] can be left intact).
> 
> If it will help, I can try to make these changes, once the MMX support
> for x86 is in place.

I'm sure we could make something work.  What concerns me is that it be
reasonable enough that people who are not familiar with the x86 won't
write code that breaks it.  Having REGISTER_RAW_SIZE be zero is on the
edge, and now we're positing further things to maintain register_valid
...

I have another proposal in mind which is more work, and more invasive,
but is more generally useful.  It would allow us to solve this
problem, and implement base-relative FP register numbering (as
discussed long ago on the EGCS list), and deal with some others I
think I remember hearing about over the years.  I'll describe it here
soon.

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