Hi David,

On Wed, Jan 7, 2015 at 4:59 PM, David T. Lewis <lewis@mail.msen.com> wrote:

Hi Eliot,

$ grep -r DOUBLE_WORD_ALIGNMENT *
Cross/vm/sqMemoryAccess.h:#if defined(DOUBLE_WORD_ALIGNMENT) || defined(DOUBLE_WORD_ORDER)
Cross/vm/sqMemoryAccess.h:#else /*!(DOUBLE_WORD_ORDER||DOUBLE_WORD_ALIGNMENT)*/
Cross/plugins/FilePlugin/sqFilePluginBasicPrims.c:#if DOUBLE_WORD_ALIGNMENT
Cross/plugins/FilePlugin/sqFilePluginBasicPrims.c:#if DOUBLE_WORD_ALIGNMENT
Cross/plugins/FilePlugin/sqFilePluginBasicPrims.c:#if DOUBLE_WORD_ALIGNMENT
Cross/plugins/FilePlugin/sqFilePluginBasicPrims.c:#if DOUBLE_WORD_ALIGNMENT
iOS/vm/iPhone/config.h:/* #undef DOUBLE_WORD_ALIGNMENT */
Mac OS/vm/config.h:/* #undef DOUBLE_WORD_ALIGNMENT */
unix/vm/config.cmake:TRY_RUN (DOUBLE_WORD_ALIGNMENT tmp ${bld} ${config}/testDoubleWordAlignment.c)
unix/vm/config.cmake:CONFIG_DEFINE (DOUBLE_WORD_ALIGNMENT)
win32/vm/sqWin32.h:# undef DOUBLE_WORD_ALIGNMENT
win32/vm/sqConfig.h:# define DOUBLE_WORD_ALIGNMENT

So it looks like DOUBLE_WORD_ALIGNMENT is used in FilePlugin to handle setting
fields in the SQFile data structure. It looks like it is trying to deal with
alignment of members of C data structures, which would vary by compiler and
platform. It does not look like something that would be related to word size
on the object memory, rather it looks like an optimization to handle different
compiler conventions in laying out C data structures.

It is one side of two linked issues. DOUBLE_WORD_ALIGNMENT is true if the platform is sensitive to 32-bit alignment, i.e. if moving an object from or to a memory address on an odd 32-bit boundary would cause an error. This is only an issue if objects are only aligned on a 32-bit boundary. Since all our platforms are affected by this (since e.g. with SSE2, x86 will cause an error if one attempts to move e.g. a double to/from an odd 32-bit address) we can reduce this to the second issue. If objects are aligned on 32-bit boundaries (as they are in the standard 32-bit VM) then care must be taken when moving aligned data to/from objects. Hence OBJECTS_32BIT_ALIGNED actually expresses the problem better.

Judging by the name, OBJECTS_32BIT_ALIGNED sounds like it is addressing
a different issue? But I do not understand the intent of the change.

The intent is to avoid generating the expensive alignment-insensitive code in the 64-bit VM and in Spur, where all objects are aligned on a 64-bit boundary.

Dave

On Wed, Jan 07, 2015 at 04:57:45PM -0500, David T. Lewis wrote:
> Hi Eliot,
>
> I'm pretty sure you have access to do the update.
>
> I am away and can't check now, but I'd suggest just do a grep -r through
> the trunk SVN and make sure nobody is using DOUBLE_WORD_ALIGNMENT. I don't
> know what it is used for without checking.
>
> The plugin change sounds good, although you might want to call it
> "re_config" instead of "reconfig" because "reconfig" suggests another
> meaning ;-)
>
> Dave
>
> > Hi David, Hi All,
> >
> >
> > I need to make some changes to platforms/Cross/plugins, which is
> > shared
> > between the trunk vm and the Cog branch.
> >
> > 1. DOUBLE_WORD_ALIGNMENT changes to OBJECTS_32BIT_ALIGNED. In Spur
> > objects
> > are always 64-bit aligned, even in the 32-bit version, so none of the slow
> > access to avoid unaligned float access is necessary. I've written it like
> > this in platforms/Cross/vm/sqMemoryAccess.h. The changes begin on the #if
> > (SQ_IMAGE64 || SPURVM) line
> >
> > #if (SQ_VI_BYTES_PER_WORD == 4)
> > # define SQ_IMAGE32 1
> > #else
> > # define SQ_IMAGE64 1
> > #endif
> >
> > #if (SQ_IMAGE64 || SPURVM)
> > # define OBJECTS_32BIT_ALIGNED 0
> > #else
> > # define OBJECTS_32BIT_ALIGNED 1
> > #endif
> >
> > 2. platforms/Cross/plugins/RePlugin/config.h gets renamed
> > to platforms/Cross/plugins/RePlugin/reconfig.h to avoid conflicts with the
> > VM's config.h
> >
> > I'm not sure that I have permission to change trunk. But if I do would it
> > be OK if I made these changes? If not, would you, David, make the change
> > to trunk's platforms/Cross/vm/sqMemoryAccess.h after which I'll check-in
> > the platforms/Cross/plugins changes?
> > --
> > best,
> > Eliot
> >
>

best,

Eliot