Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix)

Jim Blandy
2006-12-06T21:21:09Z

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.