<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 11, 2018 at 2:41 PM Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Bert,<br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 11, 2018 at 11:28 AM Bert Freudenberg <<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">No, positive depth means big endian on all platforms.</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Until Andreas added little endian support to bitblt, everything was done in big endian, and only reversed on copying to the OS window. That byte reversal was expensive, so that's why the little endian support was added, to be able to keep forms in native order on little endian platforms. Little endian is indicated by negative depth, also in the platform support code (e.g. supportsDepth).</div></div></blockquote><div><br></div><div>Thanks! I've constructed an example that shows this to me:</div><div><br></div><div>(0 to: 3) collect: [:x| | f |</div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>f := Form extent: 4@1 depth: 8.</div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>f fill: (x@0 corner: f extent) rule: Form over fillColor: Color white.</div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>ByteArray adoptInstance: f bits.</div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>f bits] #(#[255 255 255 255 0 0 0 0] #[255 255 255 0 0 0 0 0] #[255 255 0 0 0 0 0 0] #[255 0 0 0 0 0 0 0])</div><div>(0 to: 3) collect: [:x| | f |</div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>f := Form extent: 4@1 depth: -8.</div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>f fill: (x@0 corner: f extent) rule: Form over fillColor: Color white.</div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>ByteArray adoptInstance: f bits.</div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>f bits] #(#[255 255 255 255 0 0 0 0] #[0 255 255 255 0 0 0 0] #[0 0 255 255 0 0 0 0] #[0 0 0 255 0 0 0 0])</div></div></div></div></blockquote><div><br></div><div>and revealed a bug in Spur's adoptInstance: code on 64-bits...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">- Bert -<br></div><div><div dir="ltr" class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540gmail_signature"><div dir="ltr"><div><div dir="ltr"></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 11, 2018 at 11:14 AM Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi All,<div><br></div><div> in trying to fix a bug in BitBLT to do with accessing a word following a bitmap I have had to understand Form and BitBlt's extensions for handling multiple byte order. In particular, if a Form has a negative depth its byte ordering is reversed w.r.t. a Form with positive depth.</div><div><br></div><div>But in examining this code I think I have found an inconsistency, and I urgently need to check my understanding. In the Form and BitBlt code, a negative depth is stated to mean a Form whose bits are in little-endian byte order:</div><div><br></div><div><i>Form methods for accessing</i></div><div><b>depth</b></div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540m_5929463801066235012gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>^ depth < 0 ifTrue:[0-depth] ifFalse:[depth]</div><div><div><b>nativeDepth</b></div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540m_5929463801066235012gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>"Return the 'native' depth of the receiver, e.g., including the endianess"</div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540m_5929463801066235012gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>^depth</div><div><br></div><div><div><i>Form methods for testing</i></div><div><b>isBigEndian</b></div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540m_5929463801066235012gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>"Return true if the receiver contains big endian pixels, meaning the left-most pixel is stored in the most significant bits of a word."</div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540m_5929463801066235012gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>^depth > 0</div></div><div><div><b>isLittleEndian</b></div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540m_5929463801066235012gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>"Return true if the receiver contains little endian pixels, meaning the left-most pixel is stored in the least significant bits of a word."</div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540m_5929463801066235012gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>^depth < 0</div></div><div><br></div><div>and BitBltSimulation (the Smalltalk code for the plugin that implements BitBlt) has two instance variables destMSW and sourceMSW that are true if the destination form or source form has a positive depth:</div><div><br></div><div><i>BitBltSimulation methods for interpreter interface</i></div><div><div><b>loadBitBltDestForm</b></div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540m_5929463801066235012gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>"Load the dest form for BitBlt. Answer false if anything is wrong, true otherwise."</div><div><br></div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540m_5929463801066235012gmail-Apple-tab-span" style="white-space:pre-wrap"> ...
destDepth := interpreterProxy fetchInteger: FormDepthIndex ofObject: destForm.</span></div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540m_5929463801066235012gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>destMSB := destDepth > 0.</div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540m_5929463801066235012gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>destDepth < 0 ifTrue:</div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540m_5929463801066235012gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>[destDepth := 0 - destDepth].</div></div><span style="white-space:pre-wrap"> ...</span></div><div><b>loadBitBltSourceForm</b></div><div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540m_5929463801066235012gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>"Load the source form for BitBlt. Return false if anything is wrong, true otherwise."</div><span style="white-space:pre-wrap"> ...</span><div><span class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540m_5929463801066235012gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>sourceDepth := interpreterProxy fetchInteger: FormDepthIndex ofObject: sourceForm.</div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540m_5929463801066235012gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>sourceMSB := sourceDepth > 0.</div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540m_5929463801066235012gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>sourceDepth < 0 ifTrue:</div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540m_5929463801066235012gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>[sourceDepth := 0 - sourceDepth].</div><div dir="ltr" class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540m_5929463801066235012gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><span style="white-space:pre-wrap"> ...</span></span></div><div><span style="white-space:pre-wrap"><br></span></div><div><span style="white-space:pre-wrap">But if I have a look at the actual layout of bytes in a Form I see that the meaning of depth</span> is that if it is positive it is the *native* byte order (little endian on x86, x86-64, ARM, big end on SPARC, PowerPC):</div><div><br></div><div><div>Display fill: (0@0 extent: 1@100) rule: Form over fillColor: Color black.</div><div>(Display bits at: 1) hex '16rFF000001'</div><div><br></div><div>| bytes |</div><div>bytes := Display bits copy.</div><div>ByteArray adoptInstance: bytes.</div><div>bytes copyFrom: 1 to: 4 #[1 0 0 255]</div></div><div><br></div><div>i.e. the first word of the Display after writing the color black into the first 32-bit pixel is 16rFF000001 on Mac OS x86-64, or #[1 0 0 255] , which is little endian.</div><div><br></div><div>When the Squeak BttF VM was first written it was written on Motorola 68k Macs and PowerPC Macs, which are big-endian. So it is natural that at the time the terms isBigEndian and isLittleEndian and destMSB sourceMSB were as they are now, because the platform was big endian. But subsequently when the code was ported to Windows x86 by Andreas Raab, the meaning seems to me to have changed. Now depth > 0 implies *native* byte order, not big endian byte order, and depth < 0 implies the *opposite of native* byte order, not little endian order. Does anyone disagree? Does anyone have corroborating or contradicting evidence?</div><div><br></div><div>I ask because to make sense of the code I would at least like to change the variables in BitBltSimulation to be destNativeByteOrder and sourceNativeByteOrder, and I want to either delete Form>>isBigEndian and Form>>isLittleEndian and replace it with Form>>isNativeByteOrder, or redefine isBigEndian and isLittleEndian, eg as</div><div><br></div><div><div><b>isBigEndian</b></div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540m_5929463801066235012gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>"Return true if the receiver contains big endian pixels, meaning the left-most pixel is stored in the most significant bits of a word."</div><div><span class="m_7196984233559620603m_-7316392022538309955gmail-m_3797931408806195540m_5929463801066235012gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>^depth > 0 == Smalltalk isBigEndian</div><div><br></div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div><div><br></div></span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</blockquote></div></div>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_7196984233559620603m_-7316392022538309955gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_7196984233559620603gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>