<br><br><div class="gmail_quote">On Thu, Mar 28, 2013 at 3:36 PM, Louis LaBrunda <span dir="ltr"><<a href="mailto:Lou@keystone-software.com" target="_blank">Lou@keystone-software.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Nicolas,<br>
<div class="im"><br>
>Hi Louis,<br>
>I'm a bit late in this thread but...<br>
>Does all this really matters now with multi-byte fetching?<br>
<br>
</div>Well that's really my point. Little endian had a very, very tiny and<br>
predictably short lived advantage over big endian in single-byte fetching<br>
computers only. I'm pretty sure mainframes (big endian) with multi-byte<br>
fetching existed when little endian first came along. Anyone thinking to<br>
implement little endian should have realized it would lose that advantage<br>
soon.<br></blockquote><div><br></div><div>?? And how many bigendian micros are there in common use nowadays??</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
>If so, why the hell would multi-byte fetching annihilate the advantage<br>
>of one endianness and preserve the advantage of the other?<br>
<br>
</div>Big endian remains simple, little endian (not simple) lost the slight speed<br>
advantage.<br></blockquote><div><br></div><div>Not for many machine-level operations. AFAICT big endian's only advantage is in reading hex dumps. Thankfully I don't debug like that. Look at a marshaller or a data copier that has to deal with items of different size, e.g. extracting fields from the middle of a struct etc and little endian's advantage becomes clear.</div>
<div><br></div><div>But forgive me, I shouldn't even be starting this thread :)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
>For my problem (LargeIntegersPlugin), littleEndian remarkably fits the<br>
>implementation of LargePositiveInteger.<br>
>(Least significantByte at offset 0, next at 1, etc...).<br>
<br>
</div>Here you have a point that the code might look a little simpler in that it<br>
wouldn't have to go backwards thru the data.<br>
<br>
If I could wave a magic wand, I would make little endian go away and add<br>
large integer arithmetic in hardware.<br>
<br>
Just out of curiosity, are you playing with large integer arithmetic on the<br>
byte or word level?<br>
<div class="im"><br>
>Also, having a different endianness for Float and Integer is something<br>
>I would avoid...<br>
<br>
</div>Agreed but I would never have invented little endian in the first place.<br>
<div class="HOEnZb"><div class="h5"><br>
>If I copy finite positive float bits to an int, then the order is<br>
>preserved if and only if endianness matches.<br>
<br>
>void check_good_ordering(float af,float bf)<br>
>{<br>
>int ai,bi;<br>
>memcpy( &ai , &af , sizeof float);<br>
>memcpy( &bi , &bf , sizeof float);<br>
>assert( (af < bf) == (ai < bi) );<br>
>}<br>
><br>
>Nicolas<br>
><br>
>2013/1/21 Louis LaBrunda <<a href="mailto:Lou@keystone-software.com">Lou@keystone-software.com</a>>:<br>
>> Hi Tim,<br>
>><br>
>> I have a great deal of respect for you and I don't want to start a flame<br>
>> war but little endian is pet peeve, so here goes.<br>
>><br>
>> Little endian floats are probably the single biggest mistake in computer<br>
>> science ever. With little endian integers not far behind. I don't know of<br>
>> any value to little endian floats what so ever.<br>
>><br>
>> Little endian integers at least had some small value back when computers<br>
>> fetched one byte of data from memory at a time. They could start doing<br>
>> some arithmetic on the low order data byte while fetching the next byte.<br>
>> Little endian made the addressing/fetching easier. But once computers<br>
>> started fetching two and then four bytes at a time that advantage<br>
>> disappeared. And the disadvantage of numbers looking ass backwards in<br>
>> dumps remains to this day.<br>
>><br>
>> Little endian floats never had the above advantage (or any other that I can<br>
>> think of) because floats need to be normalized before any math can be done.<br>
>> Maybe if the exponent were fetched first, some setup work could be done (I<br>
>> doubt it) but with little endian floats, the exponent is fetched last.<br>
>><br>
>> I wish Intel would add big endian (at least for floats) to their processors<br>
>> with a switch that would allow programmers to declare which to use.<br>
>><br>
>> A side note about big endian machines and Linux. IBM touts that their<br>
>> mainframes can run 1000+ virtual copies of Linux at a time. I expect that<br>
>> Linux is compiled for big endian as I don't think any of the IBM machines<br>
>> are little endian.<br>
>><br>
>> Lou<br>
>><br>
>>>On 20-01-2013, at 9:39 AM, "David T. Lewis" <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
>>><br>
>>>> On Sun, Jan 20, 2013 at 04:52:42PM +0000, Frank Shearar wrote:<br>
>>>>><br>
>>><br>
>>>>> At the risk of sounding rather ignorant, what kind of machine would<br>
>>>>> that be? IIRC the 68k machines were big endian but they've been wiped<br>
>>>>> out now haven't they?<br>
>>>>><br>
>>><br>
>>>It has taken many years of blood, effort, toil, tears, sweat, pointed emails and sharply aimed comments, but finally, finally, my friends, at last we are *free* from the evil of Big Endian! At last we can release our families from the underground bunkers of safety and let them wander the outer world as nature intended.<br>
>>><br>
>>>><br>
>>>> Most certainly not, Edgar still has one.<br>
>>><br>
>>>Ah, him. Well, I've heard about him and his nasty habits. We're onto you Edgar!<br>
>>><br>
>>>><br>
>>>> Wikipedia gives a good summary: <a href="http://en.wikipedia.org/wiki/Endianness" target="_blank">http://en.wikipedia.org/wiki/Endianness</a><br>
>>>><br>
>>>> Older Macs are big endian, and the Squeak VM was originally written on<br>
>>>> big endian machines. ARM processors can run in either mode. Most likely<br>
>>>> they run as little endian for Linux, and I'm not sure which mode is used<br>
>>>> for RISC OS.<br>
>>><br>
>>>I've never yet come across an ARM being used in bigendian mode, but I have to assume some large customer wanted it in order to persuade ARM Ltd to pervert the natural course of things. So somewhere out there are a few million processors yearning to be released from bondage. I take comfort from the thought of the overwhelming majority of the approximately 18 *billion* ARM processors being Properly Ended.<br>
>>><br>
>>>To be honest I really think it's time we considered changing Squeak to use little-endian form for bitmaps, at least. There aren't any major systems out there that use big endian any more. If any legacy devices still need it, they can be adapted to use the same tricks that current little-endian machines have to use *every time* something is displayed on screen.<br>
>>><br>
>>>All I can say is thank goodness that the ATT 'Hobbit' processor never took off, with that insane middle-endian nonsense.<br>
>>><br>
>>>tim<br>
>> -----------------------------------------------------------<br>
>> Louis LaBrunda<br>
>> Keystone Software Corp.<br>
>> SkypeMe callto://PhotonDemon<br>
>> mailto:<a href="mailto:Lou@Keystone-Software.com">Lou@Keystone-Software.com</a> <a href="http://www.Keystone-Software.com" target="_blank">http://www.Keystone-Software.com</a><br>
>><br>
>><br>
><br>
-----------------------------------------------------------<br>
Louis LaBrunda<br>
Keystone Software Corp.<br>
SkypeMe callto://PhotonDemon<br>
mailto:<a href="mailto:Lou@Keystone-Software.com">Lou@Keystone-Software.com</a> <a href="http://www.Keystone-Software.com" target="_blank">http://www.Keystone-Software.com</a><br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>