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

[Jim Blandy <jimb@codesourcery.com>]

"Ulrich Weigand" <uweigand@de.ibm.com> writes:
>> 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 ...

r2v would create a computed lvalue V whose closure indicates how the
value is encoded in the register.  V's contents are the decoded
register contents.  Common code goes and creates a value W referring
to a sub-field of the value.  W contains offset, bitpos and bitsize
values indicating the sub-field's position within the decoded
contents.

When W is read, its 'read' function is called, which reads the
register, does the decoding, and then extracts the appropriate
portion.

When W is assigned to, its 'write' function is called, which can do
the appropriate decode-modify-encode steps, and write the re-encoded
value back to the register.

The key is that r2v knows how to both decode the register's contents,
and how to re-encode both the full contents, or a portion of the
contents, so it can leave enough information in the closure to tell
v2r how to handle component writes.