On Thu, Mar 28, 2013 at 3:36 PM, Louis LaBrunda
<Lou at keystone-software.com>wrote:

> 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.
>

??  And how many bigendian micros are there in common use nowadays??


>
> >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.
>

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.

But forgive me, I shouldn't even be starting this thread :)



>
> >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
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130401/efb59fb0/attachment.htm