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

[Jim Blandy <jimb@codesourcery.com>]

Daniel Jacobowitz <drow@false.org> writes:
> On Wed, Dec 06, 2006 at 01:21:48PM -0800, Jim Blandy wrote:
>> 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.
>
> What about the fact that Vladimir wanted it for memory bitfields too?
> Nothing architecture-specific about that.

I'm not sure I think it's a great idea there, either.  I want to write
up an explanation of why (essentially, because you're just replacing
the problem of too many reads with the problem of too few reads), but
I'm crunched at the moment, and haven't had time to make sure I
actually understand what everyone has written.

>> 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.
>
> Then let's not add the kludge at all.

If the alternative you have in mind is, let's give r2v the ability to
construct any kind of value it wants, and v2r access to the whole
value, thus solving Ulrich's problem, and then get computed lvalues in
to solve the Alpha's problem, then I'm in agreement.