[Vm-dev] The byte order fallacy

[Nicolas Cellier]

Hi Ben,
last year I added SQ_SWAP_4_BYTES and SQ_SWAP_8_BYTES macros in
platforms/Cross/vm/sqMemoryAccess.h
These macros use the compiler intrinsics if possible.
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c0da5abcc7a538efd3ab6dcc4bb2d2ef3ac5c65a
So we should not define any new one and rather replace the suboptimal ones
with the ones above.

i = *((int*)data);
is doubly bad because of possible alignment problem as you told,but also
because it introduces pointer aliasing, what the C compiler does not like,
and the standards neither (C89 C99 ...).

However, our int are 32 bits long in all supported platforms. Would it not
be the case, the VM would break in many places.
For example, you can see the cost in term of number of commits for the fact
that sizeof long < sizeof void * in LLP64 both in VMMaker and
Opensmalltalk-vm source.

2017-06-13 6:13 GMT+02:00 Ben Coman <btc at openinworld.com>:

>
> I bumped into an interesting article [1] by Rob Pike that...
> i = *((int*)data);
> #ifdef BIG_ENDIAN
> /* swap the bytes */
> i = ((i&0xFF)<<24) | (((i>>8)&0xFF)<<16) | (((i>>16)&0xFF)<<8) |
> (((i>>24)&0xFF)<<0);
> #endif
>
> is the wrong way to handle endianness since...
>   "It assumes integers are addressable at any byte offset; on some
> machines that's not true."
>   "It depends on integers being 32 bits long, or requires more #ifdefs to
> pick a 32-bit integer type."
>
> I guess some people here have byte-ordering war wounds so I'd value your
> opinion on whether I should file that as good advice.
> I notice we have a couple of instances of this...
>
> $  find platforms -name "*.c" -exec grep -Hi "<<" {} \; | grep ">>" | grep
> 24 | grep 8
> ./win32/plugins/FontPlugin/sqWin32FontPlugin.c:  #define BYTE_SWAP(w) ((w
> << 24) | ((w & 0xFF00) << 8) | ((w >> 8) & 0xFF00) | (w >> 24))
> ./win32/vm/sqWin32Window.c:   #define BYTE_SWAP(w) w = (w<<24) |
> ((w&0xFF00)<<8) | ((w>>8)&0xFF00) | (w>>24)
>
> cheers -ben
>
> [1] https://commandcenter.blogspot.com.au/2012/04/byte-order-fallacy.html
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170613/767f8178/attachment.html>