[squeak-dev] [Vm-dev] Accelerating LargeIntegersPlugin phase 2

Louis LaBrunda Lou at Keystone-Software.com
Thu Mar 28 22:36:17 UTC 2013


Hi Nicolas,

>Hi Louis,
>I'm a bit late in this thread but...
>Does all this really matters now with multi-byte fetching?

Well that's really my point.  Little endian had a very, very tiny and
predictably short lived advantage over big endian in single-byte fetching
computers only.  I'm pretty sure mainframes (big endian) with multi-byte
fetching existed when little endian first came along.  Anyone thinking to
implement little endian should have realized it would lose that advantage
soon.

>If so, why the hell would multi-byte fetching annihilate the advantage
>of one endianness and preserve the advantage of the other?

Big endian remains simple, little endian (not simple) lost the slight speed
advantage.

>For my problem (LargeIntegersPlugin), littleEndian remarkably fits the
>implementation of LargePositiveInteger.
>(Least significantByte at offset 0, next at 1, etc...).

Here you have a point that the code might look a little simpler in that it
wouldn't have to go backwards thru the data.

If I could wave a magic wand, I would make little endian go away and add
large integer arithmetic in hardware.

Just out of curiosity, are you playing with large integer arithmetic on the
byte or word level?

>Also, having a different endianness for Float and Integer is something
>I would avoid...

Agreed but I would never have invented little endian in the first place.

>If I copy finite positive float bits to an int, then the order is
>preserved if and only if endianness matches.

>void check_good_ordering(float af,float bf)
>{
>int ai,bi;
>memcpy( &ai , &af , sizeof float);
>memcpy( &bi , &bf , sizeof float);
>assert( (af < bf) == (ai < bi) );
>}
>
>Nicolas
>
>2013/1/21 Louis LaBrunda <Lou at keystone-software.com>:
>> Hi Tim,
>>
>> I have a great deal of respect for you and I don't want to start a flame
>> war but little endian is pet peeve, so here goes.
>>
>> Little endian floats are probably the single biggest mistake in computer
>> science ever.  With little endian integers not far behind.  I don't know of
>> any value to little endian floats what so ever.
>>
>> Little endian integers at least had some small value back when computers
>> fetched one byte of data from memory at a time.  They could start doing
>> some arithmetic on the low order data byte while fetching the next byte.
>> Little endian made the addressing/fetching easier.  But once computers
>> started fetching two and then four bytes at a time that advantage
>> disappeared.  And the disadvantage of numbers looking ass backwards in
>> dumps remains to this day.
>>
>> Little endian floats never had the above advantage (or any other that I can
>> think of) because floats need to be normalized before any math can be done.
>> Maybe if the exponent were fetched first, some setup work could be done (I
>> doubt it) but with little endian floats, the exponent is fetched last.
>>
>> I wish Intel would add big endian (at least for floats) to their processors
>> with a switch that would allow programmers to declare which to use.
>>
>> A side note about big endian machines and Linux.  IBM touts that their
>> mainframes can run 1000+ virtual copies of Linux at a time.  I expect that
>> Linux is compiled for big endian as I don't think any of the IBM machines
>> are little endian.
>>
>> Lou
>>
>>>On 20-01-2013, at 9:39 AM, "David T. Lewis" <lewis at mail.msen.com> wrote:
>>>
>>>> On Sun, Jan 20, 2013 at 04:52:42PM +0000, Frank Shearar wrote:
>>>>>
>>>
>>>>> At the risk of sounding rather ignorant, what kind of machine would
>>>>> that be? IIRC the 68k machines were big endian but they've been wiped
>>>>> out now haven't they?
>>>>>
>>>
>>>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.
>>>
>>>>
>>>> Most certainly not, Edgar still has one.
>>>
>>>Ah, him. Well, I've heard about him and his nasty habits. We're onto you Edgar!
>>>
>>>>
>>>> Wikipedia gives a good summary: http://en.wikipedia.org/wiki/Endianness
>>>>
>>>> Older Macs are big endian, and the Squeak VM was originally written on
>>>> big endian machines. ARM processors can run in either mode. Most likely
>>>> they run as little endian for Linux, and I'm not sure which mode is used
>>>> for RISC OS.
>>>
>>>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.
>>>
>>>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.
>>>
>>>All I can say is thank goodness that the ATT 'Hobbit' processor never took off, with that insane middle-endian nonsense.
>>>
>>>tim
>> -----------------------------------------------------------
>> Louis LaBrunda
>> Keystone Software Corp.
>> SkypeMe callto://PhotonDemon
>> mailto:Lou at Keystone-Software.com http://www.Keystone-Software.com
>>
>>
>
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:Lou at Keystone-Software.com http://www.Keystone-Software.com



More information about the Squeak-dev mailing list