Post by Philip PaepsPost by Martijn van BuulOverigens heeft little endian wel degelijk voordelen, alhoewel het sowieso
een beetje een arbitraire keuze blijft. Zo zijn operaties op little-endian
getallen vaak eleganter op te lossen voor data op onhandige addressen; met
bigendian is dat een heel stuk minder eenvoudig. Het is niet voor niets dat
little-endian machines over het algemeen een misalignment penalty hebben,
terwijl big-endian machines het vaak voldoende reden voor een exception vinden.
De "handigheid" van de operaties zijn vooral afhankelijk van de data, dunkt
me, en niet zo zeer van de instructieset of the endianness.
Maar het formaat van de data is nou juist waar het om gaat - dat heet
endianness ;)
Simpel voorbeeldje: Het optellen van twee multi-word getallen in little
endian is vrij simpel; kwestie van een add-with-carry totdat je door je
data heen bent. Bij bigendian machines moet je opeens van achter naar voren
rekenen. Van de andere kant gelden er vergelijkbare handigheden voor
bigendian systemen.
Post by Philip PaepsLittle-endian voelt gewoon 'tegennatuurlijk' -- zo werkt de wereld niet.
Maar "De wereld" werkt ook niet big endian; "honderdvierennegentig" is noch
big endian, noch little endian; 't is meer een soort middle endian. En
het meest gangbare datumformaat hier ten lande (DD-MM-JJJJ) is toch echt
little endian.
Mij boeit het niet zo hard; ik heb geen uitgesproken voorkeur voor het een
of het ander, maar ik denk wel dat het zo onderhand eens tijd wordt om
*een* van de twee te lozen. Zo vind ik het maar knap vervelend dat mijn 2D
graphics layer z'n data graag in 32-bits little endian ARGB wil hebben,
terwijl het 3D systeempje duidelijk een big-endian insteek heeft, en sowieso
eigenlijk RGBA (bigendian) interessanter vindt, met als resultaat dat ik
het in een bijzonder vervelende "ABGR" moet moffelen. Maar goed, da's wel
bijzonder off-topic ondertussen.
Post by Philip PaepsHet feit dat de meeste big-endian machines ook strict alignment requirements
hebben staat als ik me niet vergis los van het big-endian zijn.
Niet helemaal; zie mijn optellingsvoorbeeldje. Voor een 32-bits little endian
machine valt het optellen van twee 32 bits getallen op verkeerde alignment
uiteen in het optellen van 4 16-bits getallen zonder verdere benodigde trucage;
voor een bigendian machine is het moeilijker..
Post by Philip PaepsOverigens ben ik een voorstander van exceptions bij misalignment.
Ik niet.
Post by Philip PaepsZo dwing je de developer om na te denken hoe zijn data er in memory uitziet
en bescherm je beginnende pointer-goochelaars tegen zichzelf (hoewel menig
kernel, waaronder Linux, alignment traps vangt en achter de schermen emuleert
... in ruil voor een moordende performance hit).
En dus is het kind met het badwater weggegooid. Bovendien leidt de stricte
alignment tot verplichte padding, ook waar dat helemaal niet handig is, en
het prettiger zou wezen om te kunnen optimaliseren op ruimte.
Bovendien zitten die beginnende pointergoochelaars toch vast te goochelen
op een i386, en hebben ze *zelf* niet zo'n last van. Pas als je hun
goocheltruukje in een bigendian theater wil opvoeren komt de aap uit de
mouw (ipv het konijn uit het hoedje). Maar dan is die oorspronkelijke
goochelaar vast verdwenen...
--
Martijn van Buul - ***@dohd.org