Elke werkdag behandelt Computable een onderwerp waarover lezers kunnen discussiëren. Vandaag over het verschil tussen big-endian en little-endian, en dat dat er nu niet meer toe doet. De strijd is voorbij.
Het fundamentele verschil in endianness (of bytevolgorde) van verschillende computerarchitecturen is jarenlang een punt van discussie geweest: welke is beter, welke draait de meeste software, welke verovert de wereld? Big-endian is simpel gezegd een telmethode die begint bij het belangrijkste (grootste) getal en die dan aftelt. Little-endian is als ‘normaal tellen’: vanaf bijvoorbeeld één en dan oplopend. Van oudsher is big-endian in gebruik in IBM’s z-mainframes, naast oude systemen met Motorola’s 68000-processors en Suns Sparc-chips. De marktdominante x86-processors van Intel zijn juist little-endian.
Anno 2015 lijkt de strijd in de computerwereld voorbij. x86 heeft immers de server- en pc-werelden veroverd. Verder werkt IBM hard aan little-endian Linux voor op zijn zware systemen met Power-processors. Big-endian boet dus in aan belang (behalve op het gebied van ip). Het zal net als mainframes niet helemaal verdwijnen, maar het heeft de strijd verloren. De Lilliputters van Gulliver’s Reizen hebben gewonnen. Wat vind jij?
De stelling klopt niet! Big-endian is als gewoon tellen. Het meest significante cijfer staat voorop. Vierduizendéénendertig schrijven we als 4031, en niet als 1304, of, als we 2 cijfers in een byte stoppen, 3140.
Big-endian is dus vanuit ons, de mens, gezien het meest logisch.
Echter, als wij alleen in hogere programmeertalen programmeren, en geen Big-endian processoren op Little-endian architecturen willen emuleren, dan boeit het eigenlijk helemaal niet.
Conclusie: de minst logische volgorde “heeft gewonnen”, maar ik eet er geen hagelslag minder om!
Ach Frank, er zijn maar zo weinig mensen die ooit met dit soort problemen te maken hebben gehad dat ik me er niet zo sappel over maak.
Pas als je lowlevel stuff multiplatform (lees multi cpu) wil maken (been there done that) of dingetjes in assembler doet kom je dit soort issues tegen.
Ik betwijfel of al die jonge talenten uberhaupt weten waar dit topic over gaat.
@Pascal
Je vergeet dat je hier bijvoorbeeld wel mee te maken krijgt als je migraties van software (databases/dataopslag) uitvoert van het ene platform naar het andere platform waarbij er verschil in endian methodiek is. Voor veel database beheerders is dit nog steeds een “hot”-item, maar ik geef toe dat in mijn deelgebied de verwarring/onbekendheid omtrent dit onderwerp ook bij die doelgroep aanwezig is.
@Marco, je vergeet dat voor dit soort migraties er over het algemeen migratie-tools ingezet worden, die van zowel source als target platform kennis hebben (niet alleen endian-ness, maar ook data-representatie. Byte/Word/Long/Double/Quad) en ook met zaken als EBCDIC t.o.v. ASCII overweg kunnen. Dus ook migraties worden uitgevoerd zonder zich over de onderliggende structuren zorgen te hoeven maken…
Het probleem is ontstaan door het verschil tussen positieve en negatieve getallen. Een getal is al snel groter dan 1 of 2 bytes maar moest wel herkend worden als + of -. Bij geheugengroottes van 2, 4 of 6K moest je woekeren met de bits. De afspraak was dat het meest significante bit werd gebruikt voor deze herkenning. Een 1 betekende een negatief getal. Wie dus als meest significante bit een 1 heeft staan bij de bank heeft een schuld…
Vervolgens speelde deze “menselijke” manier van tellen de makers van “kleine” hardware parten bij de adressering. Bv Intel met de 8 bit processor 8080 en vervolgens de snellere 8088, de 8086 (16 bits), 80186 etc. systemen. IBM moest dit probleem al 20 jaar eerder oplossen en deed dit op de logische endian manier.
Andere problemen ontstonden door de menselijke taal. Voor de codering van de toetsenborden van de bolletjes schrijfmachine werd EBCDIC gebruikt. Deze schrijfmachine kenmerkte zich door en elektrische verbinding tussen de toetsen en het bolletje. De de mechanische verbinding (hardware) tussen letter op de toets en letter op de printstang (afdruk) was hiermee verbroken. Een groot voordeel, want met een QWERTY toetsenbord kon je een AZERTY bolletje gebruiken. De eeduidige definitie van toetsenbord en bolletje was de “codepage”. De “eenvoudige” microcomputers werkten in eerste instantie alleen met 64 en later 128 ASCII tekens; heel wat minder geavanceerd dan EBCDIC.
Jonge talenten zonder historisch besef zullen zich nog steeds moeten behelpen met alle workarounds die sinds beging ’70 jaren van de vorige eeuw bedacht en gemaakt zijn om de verschillen in menselijke logica en technische implementatie op te lossen.
Misschien dat er ook een klein deel is van deze talenten die een “end-user-oriented” oplossing kan realiseren voor onze ICT geschiedenis. Het wordt tijd om de exclusieve “houtje touwtje architectuur” die aan elkaar hangt van symptoom oplossende workarounds te vervangen door een “lean and mean” inclusieve en transparante architectuur waarin we en passant ook nog een paar andere veiligheids- en privacyproblemen oplossen…
@Dick van Elk:
Volgens mij heb je ergens een klok horen luiden, maar weet je niet helemaal hoe laat het is… 😉
Jij begint met de uitleg van het 1s complement, terwijl het 2’s complement overal (big & little endian) de standaard is:
https://nl.wikipedia.org/wiki/Two%27s_complement
Vervolgens haal je de breedte van de data- en adresbus door elkaar. De 8088 en 8086 hebben beide een 20-bits adresbus, die intern in 32-bits werden opgeslagen, waarbij je 2^12 mogelijkheden hebt om hetzelfde adres aan te duiden.
En binary coded decimal (BCD) heeft niks met (bolletjes)typmachines te maken. Dat is ooit ontwikkeld (mogelijk met Cobol) om digitaal exact met het 10-tallige stelsel te kunnen rekenen, zonder dat je afrondingsfouten krijgt (0,1 is binair niet exact op te slaan, net zoals we 1/3 decimaal niet exact kunnen schrijven). De uitgebreide versie van BCD, EBCDIC (extended binary coded decimal interchange code) is een soort ASCII code, ontwikkeld door IBM, voor hun mainframes, niet voor hun typemachines.
Maar toch heb je een knap stukje geschreven: dit gaat over Big-endian en Little-endian, en werkelijk helemaal niks van wat je hebt geschreven heeft er ook maar iets mee te maken!
Tot slot een vraag: pleit je met je laatste alinea voor het overgaan op MSB first, oftewel Big-endian?
@Erwin
Gelukkig wel, maar t.b.v. minimaliseren downtime en andere zaken is goede voorbereiding in zo’n geval een schone zaak (een simpel voorbeeld hier http://remidian.com/2012/07/transporting-an-oracle-database-to-another-os-platform-the-fastest-way/).
Ik weet van in ieder geval 1 (obscure) geval waarbij een migratie van een grote database vendor m.b.t. een specifiek complex datatype “as is” niet mogelijk is via zo’n migratie tool.
Het zou ook te geweldig zijn dat alles (business)scenario’s door zo’n tool bij voorbaat afgedekt zouden kunnen worden.
Goed voorbereiden is ook hier het halve werk.
Anno 2015 zou je moeten weten dat mobiel steeds belangrijker wordt, en de daar dominante arm processoren zijn bi-endian.
Nooit een EBDIC systeem tegen gekomen (en toch met heel wat rariteiten gewerkt).
Wel eens ooit een 6bits terminal gehad.
Wie mij kan vertellen wat dat voor gevolgen heeft op een unix systeem verdiend het ‘Krasse Knarren’ award 😉
Little endian architecturen zijn sneller voor het uitwerken op optellen en aftrekken met multibyte datatypes. Je begint immers altijd met het minst significate cijfer. In een big endian architectuur moet je weten hoe lang het datatype is, dan op de adresbus vooruitspringen en dan weer teruglopen.
Overigens zijn zowel little als big endian architecturen vreemd mbt de nummering van bits in een byte. Men telt bv 76543210 en dan volgt bit 8 direct na bit 0. De bitnummering volgens de iec 61131 norm, zoals gebruikt in de industriële automatisering, is wat dat betreft het meest logisch.