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@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