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

["Ulrich Weigand" <uweigand@de.ibm.com>]

Daniel Jacobowitz wrote:

> I suppose there's times we want to destroy the rest of the register,
> so knowing where it is in the register isn't enough?

The problem is, we don't *know* where it is in the register.

For example, on the SPU "char" values are placed in byte 3 of
the 16 bytes of a general purpose register, "short" values are
placed in bytes 2 and 3, and "int" values are placed in bytes
0 .. 3.  ("long long" is placed in 0 .. 7.)

However, structs are placed into registers starting from 
byte 0 always.

So if we have

  struct { char x; char y; char z; char w; } s;
  char t;

and both s and t reside in registers, then a value to access
t would look exactly the same as a value to access s.x (i.e.
type "char", lval_regnum, value_offset == 0), but to access
them requires using different bytes of the register.

We might be able to fix this particular problem by having
value_from_register somehow set the value_offset to 3 when
retrieving a value of type "char" from a register.  However,
even though there is a comment saying "The assumption is that
REGISTER_TO_VALUE populates the entire value including the
location.", that isn't actually possible with the current
interface since REGISTER_TO_VALUE doesn't actually *get*
the value itself.

So maybe we can extend REGISTER_TO_VALUE by an argument to
return the byte offset of the original value in the register,
and extend VALUE_TO_REGISTER by an argument to pass the 
requested byte offset (which might point to a subobject of
the whole object), this could work ...

We'd still have to solve the bitfield problem, but that might
be possible in common code later on.

Bye,
Ulrich

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