Re: Variable objects laziness

[Daniel Jacobowitz <drow@false.org>]

On Wed, Nov 15, 2006 at 12:04:08PM +0300, Vladimir Prus wrote:
> > Neither before nor after this patch do I really understand what
> > "type_changeable" means so I'll trust you've got it right :-)
> 
> Do you want to me add a comment to that function?

Since you seem to know what it's used for and why it relates to
fetching things, yes please.

> > Will we do eight reads from the target for this?
> > 
> >   struct x {
> >     unsigned char a:1, b:1, c:1, d:1, e:1, f:1, g:1, h:1;
> >   };
> 
> No. Look at value_primitive_field. For bitfeilds, it calls
> unpack_field_as_long, passing value_contents (args1) to it. The
> value_contents function will read entire structure from memory on the first
> time. For the second bitfield, the already-read data will be used.

Oh.  So non-bitfield members will be read lazily, but bitfield members
will cause a read of their immediate container.  That's a little
strange, but since I think it's exactly what we want to happen right
now, let's leave it alone :-)

> I think I can address this issue by making install_new_value always fetch
> values of unions.
> 
> Or I can do nothing, because in CLI, if your program is:
> 
>     struct S
>     {
>         union {
>            int i;
>            int j;
>         };
>     };
> 
>     int main()
>     {
>         S s;
>         .....
> 
> And you do:
> 
>     print s.i
>     print s.j
> 
> it will generate two reads of memory too.

Right - but only one read for "print s".  If you think fetching the
value of unions is reasonable, let's do that.

> What do you mean? The second line is indented 6 spaces, so it can use tab
> for indentation.

Sorry, you're right!

When you're ready, please repost.  Might want to finish talking with
Nick first.

-- 
Daniel Jacobowitz
CodeSourcery