Re: [Vm-dev] Accelerating LargeIntegersPlugin phase 2
Locked
Re: [Vm-dev] Accelerating LargeIntegersPlugin phase 2
 
|
On 20-01-2013, at 9:39 AM, "David T. Lewis" <[hidden email]> 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 -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim The halfway point between right and wrong is still damn wrong. Compromise isn't always a solution |
Re: [Vm-dev] Accelerating LargeIntegersPlugin phase 2
|
|
On Sun, Jan 20, 2013 at 10:51:42AM -0800, tim Rowledge wrote:
> > On 20-01-2013, at 9:39 AM, "David T. Lewis" <[hidden email]> 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. > I was assuming that this was a joke, riffing on "Middle Earth". It certainly sounded like a joke ... but googling "hobbit processor" seems to indicate it was real. Maybe real *and* a joke :) Dave |
Re: [Vm-dev] Accelerating LargeIntegersPlugin phase 2
|
|
On 20-01-2013, at 12:52 PM, "David T. Lewis" <[hidden email]> wrote: >> All I can say is thank goodness that the ATT 'Hobbit' processor never took off, with that insane middle-endian nonsense. >> > > I was assuming that this was a joke, riffing on "Middle Earth". It certainly > sounded like a joke ... but googling "hobbit processor" seems to indicate > it was real. Maybe real *and* a joke :) Indeed, both. I note that the wikipedia page is, as so often the case, wrong - wrong! - about what happened wrt the Active Book. ABC did not swap to using the Hobbit, the company was bought by ATT and essentially killed off with some of the staff taken on by EO as support personnel. The Active Book (http://research.microsoft.com/en-us/um/people/bibuxton/buxtoncollection/detail.aspx?id=158) was cancelled. I ended up at ParcPlace. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Any program that runs right is obsolete. |
From Blefuscu Re: [squeak-dev] Re: [Vm-dev] Accelerating LargeIntegersPlugin phase 2
|
|
In reply to this post by timrowledge
On 1/20/13 3:51 PM, "tim Rowledge" <[hidden email]> wrote: >> >> Most certainly not, Edgar still has one. Two G4's in working conditions > Ah, him. Well, I've heard about him and his nasty habits. We're onto you > Edgar! When Squeak born in Apple they have 68000 computers, so Big Endian. But you're right , word based microprocessors waste memory space. A old Byte magazine say Best 8 bits microprocessor = 6502 Best 16 bits microprocessor = Z80 Best 32 bits microprocessor = 68000 Sure you don't agree and like to read your opinion Edgar P.S. Enjoy you mention me :=) |
Re: From Blefuscu Re: [squeak-dev] Re: [Vm-dev] Accelerating LargeIntegersPlugin phase 2
|
|
On 20-01-2013, at 2:13 PM, "Edgar J. De Cleene" <[hidden email]> wrote: > > > > On 1/20/13 3:51 PM, "tim Rowledge" <[hidden email]> wrote: > >>> >>> Most certainly not, Edgar still has one. > > Two G4's in working conditions I have to admit that I do indeed have an old PPC mac mini as a house control server ( Indigo running my Insteon powerline network switchgear around the house; a pretty good setup). But I don't run Squeak on it. > A old Byte magazine say > Best 8 bits microprocessor = 6502 > Best 16 bits microprocessor = Z80 > Best 32 bits microprocessor = 68000 That was decently true in say 1984, though you could certainly argue that the NatSemi 32000 series was cleaner architecturally; they took the whole orthogonal registers/addressing modes/etc thing very seriously. Unfortunately they totally screwed up the execution and the cpu's performance was *dismal*. In some of the code I wrote for a 3D design system back then, my BBC micro (2MHz 6502) was faster. But by '87 the ARM was on the scene even thought most people wouldn't even hear of it for another decade. The very first ARM cpus running at 8MHz would outrun anything intel had at the time by at least a factor of 2. That was a cpu with no cache at all, not even an instruction prefetch queue. But Big Endian? No excuse. Just no possible excuse for it. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Never write software that anthropomorphizes the machine. They hate that. |
Re: From Blefuscu Re: [squeak-dev] Re: [Vm-dev] Accelerating LargeIntegersPlugin phase 2
|
|
On Sun, Jan 20, 2013 at 04:33:02PM -0800, tim Rowledge wrote:
> > But Big Endian? No excuse. Just no possible excuse for it. Dunno Tim. Next you'll be telling us that motorcycle electrics should all be negative ground, and we all know that ain't so ;-) Dave |
|
|
David T. Lewis wrote:
similar... http://xkcd.com/567/On Sun, Jan 20, 2013 at 04:33:02PM -0800, tim Rowledge wrote: |
[Vm-dev] Accelerating LargeIntegersPlugin phase 2
|
|
In reply to this post by timrowledge
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" <[hidden email]> 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:[hidden email] http://www.Keystone-Software.com |
Re: From Blefuscu Re: [squeak-dev] Re: [Vm-dev] Accelerating LargeIntegersPlugin phase 2
|
|
In reply to this post by David T. Lewis
On 20-01-2013, at 7:13 PM, "David T. Lewis" <[hidden email]> wrote: > On Sun, Jan 20, 2013 at 04:33:02PM -0800, tim Rowledge wrote: >> >> But Big Endian? No excuse. Just no possible excuse for it. > > Dunno Tim. Next you'll be telling us that motorcycle electrics should all > be negative ground, and we all know that ain't so ;-) I thought my motorcycle was controlled by a series of tubes... tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- During evolution his ancestors were in the control group. |
Re: [Vm-dev] Accelerating LargeIntegersPlugin phase 2
|
|
In reply to this post by Louis LaBrunda
Hi Louis,
I'm a bit late in this thread but... Does all this really matters now with multi-byte fetching? If so, why the hell would multi-byte fetching annihilate the advantage of one endianness and preserve the advantage of the other? For my problem (LargeIntegersPlugin), littleEndian remarkably fits the implementation of LargePositiveInteger. (Least significantByte at offset 0, next at 1, etc...). Also, having a different endianness for Float and Integer is something I would avoid... 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 <[hidden email]>: > 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" <[hidden email]> 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:[hidden email] http://www.Keystone-Software.com > > |
[Vm-dev] Accelerating LargeIntegersPlugin phase 2
|
|
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 <[hidden email]>: >> 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" <[hidden email]> 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:[hidden email] http://www.Keystone-Software.com >> >> > Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:[hidden email] http://www.Keystone-Software.com |
Re: [Vm-dev] Accelerating LargeIntegersPlugin phase 2
|
|
On Thu, Mar 28, 2013 at 3:36 PM, Louis LaBrunda <[hidden email]> wrote: Hi Nicolas, ?? And how many bigendian micros are there in common use nowadays??
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 :)
best, Eliot
|
[Vm-dev] Accelerating LargeIntegersPlugin phase 2
|
|
Hi Eliot,
>> 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?? There are a lot of reasons micro processor architectures survive or not. Were the early Intel little endian processors really better than the Motorola 68000 big endian designs? Intel chips and maybe even the company could have died if IBM had chosen the Motorola chip over Intel for the IBM PC. I expect if little endian were never invented, no one would miss it. We would just code with big endian data and never think about it. Would you trade little endian for more registers? >> >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. Back when they first came out that was how you had to debug. Back then it drove me nuts trying to figure out what I was looking at. >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. Is it a speed advantage or just simpler code? Is it much simpler or just a little math to get the right byte at the right time? I have a program that gets big endian float data and has to convert it to little endian float. So when little endian was invented that's just what the computing world needed, another way computers would have a hard time communicating with each other. If little endian came first, maybe I wouldn't be able to come up with a good reason to have (add) big endian but it didn't and I don't see a good reason for little endian to have been invented. It just complicated things for little value. >But forgive me, I shouldn't even be starting this thread :) Too late. Lou ----------------------------------------------------------- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:[hidden email] http://www.Keystone-Software.com |
Re: [Vm-dev] Accelerating LargeIntegersPlugin phase 2
|
|
Lou, Sure, historical reasons count, but why stopping at micro-processor era and not a few centuries back? If only european would have understood and adopted the true arabic number notation, our world would be dominated by little endian anyway ;) Speaking of communications, I note that the least significant bit in a byte is still sent first on a serial line, ethernet included, while we prefer sending most significant byte first in a 32-bit word, what a mess! Anyway, big or little, we shall better admit our inferiority: a middle endian formatted germane brain will swim in those swamps better than we will ever do (huntert drei und swanzig). ;) 2013/4/1 Louis LaBrunda <[hidden email]> Hi Eliot, |
[Vm-dev] Accelerating LargeIntegersPlugin phase 2
|
|
Hi Nicolas,
>Sure, historical reasons count, but why stopping at micro-processor era and >not a few centuries back? >If only european would have understood and adopted the true arabic number >notation, our world would be dominated by little endian anyway ;) If that were the case, I would be fine with little endian. My complaint has more to do with the confusion it caused for what I see as very little gain. >Speaking of communications, I note that the least significant bit in a byte >is still sent first on a serial line, ethernet included, while we prefer >sending most significant byte first in a 32-bit word, what a mess! Yes:( Lou ----------------------------------------------------------- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:[hidden email] http://www.Keystone-Software.com |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |