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
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.
- 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
- 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
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.
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.
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.
- 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
- 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
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.
- 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
- 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
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
vm-dev@lists.squeakfoundation.org