[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Attempting to unbox struct fields
From: |
Thompson, David |
Subject: |
Re: Attempting to unbox struct fields |
Date: |
Mon, 29 Feb 2016 16:09:01 -0500 |
On Mon, Feb 29, 2016 at 12:43 PM, Mark H Weaver <address@hidden> wrote:
> "Thompson, David" <address@hidden> 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