Managed hosting door True

Discussie

Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

‘De endian-strijd is voorbij’

 

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?

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5442795). © Jaarbeurs IT Media.

5,5


Lees meer over


 

Reacties

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.

Ik vind ..... de vraag eigenlijk totaal suf. Wie heeft er gewonnen? Was er een wedstrijd gaande dan? En wat was de prijs?

Er zijn wat technische verschillen tussen big en little endian,en het ene is soms wat handiger dan het andere, en andersom, maar per saldo is het net zo interessant als van links naar rechts schrijven of van rechts naar links; het ene is handiger als je schrijft, en het andere als je in een steen beitelt, maar het hangt er ook nog van af of je links- of rechtshandig bent, dus totaal arbitrair, en evenzo dus TOTAAL NIET INTERESSANT.

de reacties geven mooi de essentie van de ict weer. Van "vraag is totaal suf (nou en ? :-) tot de complete tegenstelling tussen Dick en Frank die wel weer beiden hoog beoordeeld worden. Maarja, vaste telefoons op hotelkamers levert ook sterren op, konden we hier laatst lezen. En aan het eind de verwijzing naar Gulliver met de kanttekening dat de lilliputters uiteindelijk wonnen. Prachtig. Ik kijk uit naar het artikel over RISC vs CISC processors ;-)

Frank opent de reacties met het door elkaar halen van little en big endian en geeft dan als conclusie: "Big-endian [hij bedoelt: little-endian] is dus vanuit ons, de mens, gezien het meest logisch."

Echter, dit geldt natuurlijk alleen voor de 'Europese mens' en mensen uit andere culturen die gewoon zijn om van links naar rechts te lezenn, maar wel de Arabische getalnotatie hebben overgenomen. Voor Arabieren, die van rechts naar links lezen, is diezelfde getalnotatie natuurlijk big-endian!

@Felix.. Laat ik daar dan alvast een knuppel in het hoenderhok gooien, en stellen dat RISC dit ook al lang gewonnen heeft. "Jamaar.. Alle Intel x86/X64 processoren zijn CISC" hoor ik al iemand jammeren. Klopt, en klopt toch ook niet. Aan de buitenkant zijn Intel X86/X64 processoren inderdaad CISC, omdat de Assembler code een groot aantal Mnemonics kent (weer zo'n ouderwets ICT woord). Maar al die Opcodes worden door de Microcode in de 'firmware' van de processor omgezet in bundels RICS-code, Daardoor lijkt een Intel CPU op een CISC Processor, maar onder de motorkap draait toch echt een RISC Core. Oke, het aantal echte machine instructies dat een Intel CPU kent is toch flink wat groter dan wat er bijvoorbeeld in MIPS of Power CPU's zit, maar er is dan ook niet echt een getal te knopen aan de term 'Reduced'

Aangezien een kleine 80% van de ICT wereld (mobieltjes en tablets daargelaten, die draaien bijna allemaal op ARM, wat ook al een RISC CPU is) op X86/X64 CPU's draait, heeft RISC dus al lang gewonnen....

@Pascal: EBDIC ken ik ook niet, maar mocht er een c-tje tussen uitgevallen zijn (ofwel: EBCDIC): deze stamt uit (o.a.) het IBM mainframe tijdperk.

Dit heeft verder geen directe impact op unix; pas bij uitwisselen data of emulatoren gaat dit een rol spelen.

Rond het millennium veel met mainframe gedaan en bij bijvoorbeeld analyseren van tracefiles is het wel handig te weten of je little- of big endian / ASCII of EBCDIC aan het lezen was.

@Felix The Cat: En wat dacht je van de strijd tussen de slash en de backslash? :-)

@PaVaKe je hebt uiteraard gelijk maar voor die vraag refereerde ik naar een 6 bits terminal, met enkel hoofdletters tot gevolg.
Daarmee kom je op een unix bak niet heel ver.
Om die reden schakelt het systeem automatisch om waneer je met enkel hoofdletters inlogd. Met Ctrl-D kun je dat weer terug draaien.
Moderne UNIX/Linux systemen lijken dat kunstje niet meer te kennen, het is ook wel legacy die werkelijk nergens over gaat.
Ik ben trouwens zelf ook nooit TN3270 tegen gekomen, maar mijn ervaring met IBM beperkt zich ook tot AIX (ehhh bijna vergeten en PC's/Laptops)

Nu ja Endianess toch een leuk onderwerp geworden.
@Rob, ik meen dat de performance winst werd gehaald op stack operaties.
Daar staat de boel n.l. weer in handzame volgorde he.
Bijna alle serieuze CPU's (that includes even Z80 & 6502) hebben wel een mogelijkheid om met indexen te werken waarmee afgezien van performance de verschillende endines verianten wel redelijk goed te implementeren zijn.

Zijn we dan eindelijk van Java af?

@Victor:
Lees deze link eens:
https://nl.wikipedia.org/wiki/Endianness

En bedenk dan nogmaals of jouw bewering dat ik fout was klopt...

En niet alleen "de Europese mens", maar veel meer mensen schrijven van links naar rechts. En dan heb je ook nog volken die tekst van rechts naar links schrijven, maar getallen van links naar rechts...

Je kunt dus wel stellen dat veruit de meeste mensen op deze aarde getallen van links naar rechts schrijven.

@Felix:
Tegenstelling tussen Dick en mij? Dick schreef een heel aardig stukje, met een foutje of twee, maar totaal off-topic. Daar wees ik hem even op.

@Rob:
Tegenwoordig zijn alle processorarchitecturen (zelfs de mobiele) 64-bits, dus hoeft er voor 99,99% van de gehele getallen (floats zijn altijd bijzonder) niet over adressen heen en weer worden gesprongen om een tellertje te verhogen of verlagen. Daarnaast, als je in een 32-bits CPU een in het geheugen opgeslagen 64-bits int aanpast, dan moet je toch eerst alle 64-bits binnenhalen uit het geheugen en vervolgens weer alle 64 bits wegschrijven naar het geheugen...

@Ewout:
Op de server zal het nog wel enige tijd blijven, en dat vind ik prima. Maar hoe eerder we op de desktop verlost zijn van Java, Flash en Silverlight, hoe beter het is!

Mijn bijdrage gaat over geschiedenis, verbanden en taal. Taal is daarin het grootste probleem voor een computer, om de eenvoudige reden dat taal ambigu is. Omdat mensen de eenvoudige computertaal moesten om zetten in begrijpelijk Nederlands, of Frans, of Chinees, of Urdu, of zelfs Engels zijn er afspraken gemaakt. Die afspraken zijn gebaseerd op standaarden. Zoals meestal, geldt bij afspraken het recht van de sterkste: de "de facto standaard.

Nog steeds is de grootste verliezer hierbij de samenleving. Er zijn mogelijk meer computertalen dan mensentalen. Bovendien is hun levensduur meestal zeer kort. Terwijl de computer toch zo'n eenvoudige (binair) aan te spreken entiteit is...

Mijn pleidooi voor de inzet van ons "jonge talent" op basis van de behoeften van onze (mondiale) samenleving, zou de enorme verspilling die, als gevolg van de ontwikkelingen in de afgelopen 50 jaar, nog steeds plaats vindt, sterk kunnen verminderen.

Uiteraard niet op basis van "mijn Volkswagen is beter dan jouw Volvo", maar op basis van een consistente, coherente architectuur. Wat betekent òf alles met alles laten "praten", òf open (transparant) en eerlijk opnieuw beginnen.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×