<div dir="ltr"><div><div><div><div><div>Hi Ben,<br>last year I added SQ_SWAP_4_BYTES and SQ_SWAP_8_BYTES macros in platforms/Cross/vm/sqMemoryAccess.h<br></div>These macros use the compiler intrinsics if possible.<br><a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c0da5abcc7a538efd3ab6dcc4bb2d2ef3ac5c65a">https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c0da5abcc7a538efd3ab6dcc4bb2d2ef3ac5c65a</a><br></div>So we should not define any new one and rather replace the suboptimal ones with the ones above.<br><br>i = *((int*)data); <br></div>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 ...).<br><br></div>However, our int are 32 bits long in all supported platforms. Would it not be the case, the VM would break in many places.<br></div>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.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2017-06-13 6:13 GMT+02:00 Ben Coman <span dir="ltr"><<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr">I bumped into an interesting article [1] by Rob Pike that... <div><div>i = *((int*)data);</div><div>#<span id="m_-7028344785490463994gmail-:19h.1">ifdef</span> BIG_<span id="m_-7028344785490463994gmail-:19h.2">ENDIAN</span></div><div>/* swap the bytes */</div><div>i = ((i&0xFF)<<24) | (((i>>8)&0xFF)<<16) | (((i>>16)&0xFF)<<8) | (((i>>24)&0xFF)<<0);</div><div>#<span id="m_-7028344785490463994gmail-:19h.3">endif</span></div></div><div><br></div><div>is the wrong way to handle endianness since... </div><div>  "It assumes integers are addressable at any byte offset; on some machines that's not true."</div><div><div><div><div>  "It depends on integers being 32 bits long, or requires more #<span id="m_-7028344785490463994gmail-:19h.5">ifdefs</span> to pick a 32-bit integer type."</div></div><div><br></div><div>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.</div></div><div>I notice we have a couple of instances of this...</div><div><br></div><div>$  find platforms -name "*.c" -exec grep -Hi "<<" {} \; | grep ">>" | grep 24 | grep 8</div><div><div>./win32/<span id="m_-7028344785490463994gmail-:19h.9">plugins</span>/<span id="m_-7028344785490463994gmail-:19h.10">FontPlugin</span>/<wbr>sqWin32FontPlugin.c:  #define BYTE_SWAP(w) ((w << 24) | ((w & 0xFF00) << 8) | ((w >> 8) & 0xFF00) | (w >> 24))<br></div><div>./win32/<span id="m_-7028344785490463994gmail-:19h.11">vm</span>/sqWin32Window.c:   #define BYTE_SWAP(w) w = (w<<24) | ((w&0xFF00)<<8) | ((w>>8)&0xFF00) | (w>>24)</div></div></div><div><br></div><div>cheers -ben</div><div><br></div><div>[1] https://<span id="m_-7028344785490463994gmail-:19h.12">commandcenter</span>.<span id="m_-7028344785490463994gmail-:19h.13">blogspot</span><wbr>.com.<span id="m_-7028344785490463994gmail-:19h.14">au</span>/2012/04/byte-order-<wbr>fallacy.html</div><div><br></div></div>
<br></blockquote></div><br></div>