On Mon, Feb 29, 2016 at 12:43 PM, Mark H Weaver <m...@netris.org> wrote: > "Thompson, David" <dthomps...@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
