[Vm-dev] Re: Changes needed to platforms/Cross/plugins

David T. Lewis lewis at mail.msen.com
Thu Jan 8 04:03:57 UTC 2015


On Wed, Jan 07, 2015 at 05:34:28PM -0800, Eliot Miranda wrote:
> Hi David,
> 
> On Wed, Jan 7, 2015 at 4:59 PM, David T. Lewis <lewis at 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.
>

Sorry, it still sounds a bit suspect to me. DOUBLE_WORD_ALIGNMENT makes
sense as you describe, and the name fits the usage. It is related to
compiler behavior, and has no direct relationship to object slot alignment
in the object memory. It is used by FilePlugin to deal with data alignment
within the SQFile data structure.

Memory alignment of slots in the object memory is a different issue, and
it might or might not be related to the DOUBLE_WORD_ALIGNMENT behavior of
the compiler and host platform on which that object memory is running.

To me, the name OBJECTS_32BIT_ALIGNED is confusing. This is Squeak, so
I assume that "OBJECT" might be related to objects, as in the things that
get aligned onto 32 or 64 bit boundaries in the object memory. Those
boundaries are related to the object memory format, not to the host
platform or compiler. I do not expect "OBJECT" to refer to the things
in e.g. a SQFile data structure.

So if you want a macro that affects alignment of "objects" in C data
structures, that would be DOUBLE_WORD_ALIGNMENT. And if you want a macro
that affects aligment of "objects" in the Squeak object memory, maybe
that is OBJECTS_32BIT_ALIGNED. But these are not the same thing, and
one should not be used in place of the other.

Dave



More information about the Vm-dev mailing list