This is the mail archive of the gdb-patches@sourceware.org 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: [RFA][2/5] New port: Cell BE SPU (valops.c fix)


That analysis of the current use of the r2v/v2r functions is really
helpful.  I feel very happy to have a thorough and detailed
explanation of what's going on.  Thank you, Ulrich.

It seems to me the hard case to deal with is the alpha STS/LDS
conversions.  If I understand properly, the alpha's issue here is as
follows:

- a 32-bit float stored in a floating-point register with LDS gets
  converted to a 64-bit floating-point value.  Extracting it with STS
  does the reverse, but in a way that preserves the exact bit pattern.
  So the LDS and STS instructions can be used to store 32-bit integers
  as well as 32-bit floats, although the integer's bits get
  re-interpreted as float fields and the value looks odd.  And this is
  the standard way to handle 32-bit integers stored in floating-point
  registers.

- a 64-bit structure can also be stored in a floating-point register,
  with no bit rearrangement.

So the alpha needs to distinguish three cases:

a) a 32-bit integer in a floating-point register, mangled as a float.

b) an integer of some size at some offset within the floating-point
  register, not mangled because it is part of a larger structure.

c) a 64-bit value stored in the register.

The alpha register_to_value function could represent a) as a value
with a bitpos of 64, indicating that special decoding is necessary.
It would represent b) and c) using normal bit positions and lengths.
Wouldn't this work?  Couldn't something similar be done for the 387?

I'm reluctant to get into storing original types and having reference
counts; it's a lot of complexity in the core code to handle
architectures that are doing odd things.

I've got unsubmitted patches for GDB that implement a new kind of
value, whose contents are read and written via functions provided by
the user, based on a generic closure pointer.  Future r2v / v2r
functions could produce values of this sort, instead of using odd
bitpos values.  So the kludge wouldn't last forever.


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