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

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Jim Blandy wrote:

> 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?

This misses the case

a') an integer (bitfield) of some size < 32 bit that is part of a
    32-bit integer in a floating-point register mangled as a float


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

Note that my original proposal did not require refcounts, since it 
did not store pointers to struct value, only to types.  (And value
already contains pointers to types, so this is nothing new.)

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

I'm not sure I see how this would solve the problem at hand: assume
r2v creates a value containing special functions to read and write
the register.  Then common code goes and creates a value refering
to a sub-field of that value.  How do we access that derived value?
Using the same access functions as provided for the full value --
but how do they know they should operate only on a part (which part)?
It would appear that this is exactly the same problem as we're
currently discussing ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com