Re: Attempting to unbox struct fields

["Thompson, David" <dthompson2@worcester.edu>]

On Mon, Feb 29, 2016 at 12:43 PM, Mark H Weaver <mhw@netris.org> wrote:
> "Thompson, David" <dthompson2@worcester.edu> writes:
>
>>> The first thing I noticed is that the patch assumes that doubles are the
>>> same size as pointers.  Obviously this is not the case on 32-bit
>>> systems.  What's the plan for those systems?
>>
>> Yeah, I just hacked this together on my x86_64 system and paid no mind
>> to portability.  I was hoping that you or Andy or Ludovic would have
>> an idea for how to address portability issues. :)
>
> I think the approach we need to take is that for 32-bit systems, doubles
> will need to use two consecutive slots.  Furthermore, those slots will
> either need to be aligned (i.e. the first slot must have an even index)
> or else the code that accesses 'double' struct fields will need to
> perform the access carefully, perhaps by copying each half separately
> into a local 'union' and then copying the double from there.

After talking with Andy on #guile for a bit, it has become apparent
that unboxing these fields will only be of limited utility.  For
example, it would be nice to eventually handle arrays of unboxed data
like in C with an array of structs, but unboxing struct fields doesn't
get us any closer to such a goal.  Thus, I am going to drop this work
and find another optimization to focus on.

Thanks anyway.  It's been an educational experience.

- Dave