User:Beginner 25/endian

A Wikipédiából, a szabad lexikonból.

A számítástechnikában, az endianitás az a tulajdonság, ami bizonyos adatok - többnyire kisebb egységek egymást követő sorozata - tárolási sorrendjéről ad információt. Tipikus esetekben ez a tulajdonság döntő fontosságú az integer értékeknek a számítógép memóriájában byte-onként való tárolása (egy memória címhez relatívan), illetve ezek hálózaton vagy más hordozón való továbbítása esetében. Ha speciálisan byte-okról beszélünk egy számítógép esetében, akkor az endianitás egyszerűen a byte sorrendre, vagy (ritkábban) a byte sex-re vonatkozik. Az eredeti angol kifejezés az endianness egy utalás arra a háborúra, amely a két szembenálló csoport között zajlik, akik közül az egyik szerint a lágytojás nagyobb végét (big-endian), míg a másik csoport szerint a lágytojás kisebb végét (little-endian) kell feltörni. Erről Swift ír a Gulliver Utazásai című könyvében.

Tartalomjegyzék

[szerkesztés] Endianitás a számítógépeken

Úgy tűnik, nincs jelentős előnye egyik tárolási módnak sem a másikkal szemben, és mindettőnek vannak követői a különböző számítógép architektúráknál. Ugyan mondhajuk, hogy a világ jelenleg inkább kicsi a végén szerint működik, mivel az Intel x86 alapú processzorok (és azok klónjai), amit a legtöbb személyi számítógép és laptop használ, a "kicsi a végén" - little-endianness módszert alkalmazza. Ezt a megoldást gyakran emlegetik, mint "Intel formátum". A hálózatok viszont általában a "nagy a végén" tulajdonságú számokat használnak a címekben; ez történetileg alakult így, ez a megoldás megengedte a telefonszámok alapján történő útvonaliránítást - routing-ot. A Motorola processzorok általában a "nagy a végén" - big-endianess megoldást használják, míg a ARM processzor rendelkezik azzal a képességgel, hogy átkapcsolható benne az endianitás, hogy nagyobb teljesítményt nyújthasson hálózati eszközben is.

Általában egy [[byte]-ot tekintünk elemi egységnek vagy legalóbb szintnek a tárolás szempontjából vagy az adtátviteli protokolok területén. Ezért az egy byte-os adatok sorozata (pl. ASCII kódolású szöveg, UTF-8-as, az ISO 8859 kódolás valamelyike) általában nem érintett az endianitás okozta problémák szempontjából. Másrészről, a szövegek változó-hosszúságú kódolása, amely a byte-ot használja egységként, mint az UTF-8, már tekinthető úgy, mint amiben "beépített" endianitási problémák is lehetnek, bár csaknem minden általánosan használt kódolási eljárás tervezésekor erre valamilyen szinten figyelmet fordítottak. Bár, a Unicode stringek UTF-16 vagy UTF-32 szerinti kódolása érintett az endianitás szempontjából, mivel minden kód egységet két vagy négy byte képvisel.

[szerkesztés] Logikai és aritmetikai leírás

Megjegyzés: a következő fejezetben minden szám hexadecimális formában kerül ábrázolásra.

Nagy a végén - Big-endian

Amikor (számos) számítógép 32 bites egész értéket, (ami legyen esetünkben 4A3B2C1D, a 100 címtől kezdve), tárol a memóriájában, ami 1 byte-os elemi tárolókból, 1 byte-onténként növekvő címekkel rendelkezik, akkor a tárolást a következők szerint végzi:

100 101 102 103
... 4A 3B 2C 1D ...

Ebben az esetben, a legjellemzőbb byte - erre általában az ismert angol kifejezést "most significant byte" használják a számítástechnikában (vagy rövidítve MSB, ami esetünkban 4A) - a memóriában az legalacsonyabb címen van tárolva, míg a következő "jellemző byte" is ( 3B) a következő címen van tárolva, és így tovább.

A továbbiakban lépjünk tovább az elemi tárolók méreteinek vonatkozásában: tegyük fel, hogy továbbra is 32 bites értéket kell tárolni, de most a tárolás elemi egységének 2 byte-ot tekintsünk, 1 byte-os címnövekedés mellett. Azonos példa mellett maradva (4A3B2C1D értéket a 100-as címtől kezdve), azonos címtartományban, a 100 és a 103 között kell tárolni, ahogyan azt a következő példa mutatja:

100 101 102 103
... 3B 4A 1D 2C ...

A legjellemzőbb elemi adat a példában most 4A3B, amit a 2C1D érték követ a 102-es címen.

A harmadik példa célja: vizsgálni a különbséget, amit az elemi tároló elem és a tárolási lépés hosszának változása okozhat. Ebben a példában is 32-bites egészet kell tárolni a memóriában, 2 byte-os elemi tárolóelem hossz, és 2 byte-os címnövelés esetén:

100 101
... 3B 4A 1D 2C ...

A legjellemzőbb elemi adat most is 4A3B a példában, amit a 2C1D érték követ, de most a 101 címen.

Azokat az architechtúrákat, amelyek a fenti szabályokat követik, nevezik "nagy a végén" vagy angolul big-endian viselkedési módúaknak, (a memorizáláshoz: a nagy vég lesz az első helyen) ide tartoznak a Motorola 68000, SPARC, PowerPC (az Intel-re való áttérés előtt az Apple's Macintosh processzora volt), és a System/370.

Más számítógépek a 4A3B2C1D értéket a következő rendben tárolják:

Kicsi a végén - Little-endian

100 101 102 103
... 1D 2C 3B 4A ...

Így, a a kevésbé jellemző ("legkisebb") byte (Az angol least significant byte kifejezés rövdítéséből LSB néven ismert) az első, és ez példánkban 1D.

100 101 102 103
... 1D 2C 3B 4A ...

A legkevésbé jellemző elemi adathoz most a 2C1D érték tartozik a példánkban, ezt követi a 4A3B a 102-es címen.

100 101
... 1D 2C 3B 4A ...

A legkevésbé jellemző elemi adat még mindig a 2C1D a példánkban, amit a 4A3B érték követ a 101 címen.

A fenti tárolási módot követő architektúrákat nevezik "kicsi a végén" vagy angol kifejezéssel little-endian (mnemonic: "little end in" - the little end goes in first, a kis vég kerül előre) módúaknak, ide tartoznak többek között a MOS Technology 6502, DEC VAX, és legtöbbet emlegetett Intel x86 alapú processzor család tagjai, ideértve az Intel Pentium alapú személyi számítógép és laptop processzorokat is.

Kicsit érthetőbb közelítés szerint, az endianitás nem a vég értékét határozza meg, hanem inkább azt, hogy melyik vég kerül előre.

Kettős-Endianitás - Bi-endinanness

Egyes architektúrák esetében beállítható vagy egyik, vagy másik endianitás; ide taroznak az ARM, PowerPC (de nem a PPC970/G5), DEC Alpha, MIPS, PA-RISC és az IA64. A bi-endian, kifejezés a hardverre azt jelenti, hogy megvan a lehetősége a processzornak, hogy a számítások vagy az adat továbbítás esetében a két lehetőség közül az egyiket használja (feltehetően létezik erre valahol egy mód beállító bit). A legtöbb architektúra szoftrveresen kapcsolhtaó át a kiválasztott endianitási módra/formára (többnyire a gép indításakor); bár léteznek olyan architektúrák amelyeknél a alapértelmezett andianitást harveresen állítják be (alaplapon), így szoftveresen nem is lehet átkapcsolni (pl. a DEC Alpha, amelyik "nagy a végén" módban működik a Cray T3E-ben).


Középső a végén - middle-endianness

Bizonyos architektúrák, amelyeket középső a végén' vagy middle-endian neveznek (vagy néha keveret endianitás vagy mixed-endian), az előzőeknél sokkal bonyolultabb tárolási módot használnak.

Ennek bemutatásához ismét amegszokott példához fordulunk: tegyük fel, hogy a 32 bites értéket most szószervezésű (egy szó 2 byte) géen kell tárolni a memóriában. Ez a memória 2 byte-os elemi egységeket képes kezelni, a címnövekmény pedig 1 byte-os.

100 101 102 103
... 4A 3B 2C 1D ...

vagy egy másik lehetőség:

100 101 102 103
... 2C 1D 4A 3B ...

A fenti példával kapcsolatosan két megjegyzést kell tenni:

  • az első példa a "nagy a végén" szerinti lehetséges megoldást mutatja, míg a másik a "kicsi a végén" szerintit.
  • A valódi megoldások ennél bonyolultabbak, a byte-ok cseréjére sokkal több lehetőség van.

Az a formátum, amiben a VAX és az ARM processzorok a kétszeres pontosságú lebegőpontos számokat tároljákT, kevert endianitású. A 32-bites szavak "középső a végén" formátumban tárolódnak a PDP-11-ben, ezért használják a pdp-endian kifejezést is, ha erre a formátumra akarnak utalni.

[szerkesztés] Bit szintű endianitás

Az endinitási koncepció kevéssé fontos a bitek byte-ban elfoglalt helyét illetően, mivel az architektúrák általában nem támogatják egyes bitek byte-on belüli címzését. A byte-on belüli bitek, bitcsoportok címzése helyett a logikai műveletek adnak jól definiált eredményeket, így mondhatjuk, hogy a bitek szempontjából az architektúrák endianitás függetlenek.

Sajnálatos módon azonban, a byte szintű endianitás mégiscsak okozhat problémákat: ha a tárolandó bit sorozat nem pontosan egy byte hosszúságú, akkor az egy byte tárolásával kapcsolatos endiantiási megfontolások mégsem hagyhatók figyelmen kívül. Egy tárol byte legszignifikánsabb bitjének az értelmezése elvezet a bit szintű endianitás kérdéseihez. Tovább bonyolítja a helyzetet, hogy egyes programnyelvek, például a C megengedi a rekord adatszerkezetben a bitmező használatát. Ebben az esetben már fel kell tételeznünk bit szintű endianitást (szerencsére ez nem architektúra szinten, hanem fordítóprogram szinten jelentkezik, azonban a hordozhatóság szempontjából egyáltalán nem elhanyagolható).

Ha egy file a memóriából rekordonként kerül olvasásra, vagy az írása úgy történik, mint egy bitekből bitekből álló nagy blokk, akkor felmerül a lehetősége annak, hogy a rekord mezői nem lesznek megfelelő byte sorrendűek. Különböző eljáráshívásokkal megvalósított konverziókkal lehet bizosítani, hogy a rekordok byte szintű endianitása megfelelő legyen. Hasonló meggondolásokat kell tenni, ha a fent említett rekordokat hálózaton keresztül adatcsomagokban továbbítják. Ekkor ugyanis lehetséges, hogy a bitcsoportok határai nem esnek egybe byte határokkal, így a küldött csomagok értelmezése szinte megjósolhatatlan lehet.

[szerkesztés] Hordozhatósági problémák

Az endianitás alapvetően érinti a szoftverek hordozhatóságát. Például, egy bináris formában tárolt adat értelmezése egy megfelelő [[bitmaszk] használatával feltétlenül érintett az endinaitás szembontjából, mivel a különböző endianitású adatok más és más eredményeket adnak, a maszk értékétől függetlenül.

Egy program által, közös formátumba felírt bináris adatok ugyancsak érintettek lehetnek: például ha az adatokat a BMP bitmap formátumban kell felírni, ("elől a kicsi" egészek), és ha az adat tárolása "elől a nagy" megoldású, akkor az adatok sérülhetnek, és nem illeszthetők az adott formátumhoz.

Software that needs to share information between hosts of different endianness typically uses one of two strategies. Either it can choose a single endianness for sharing data, or it can allow hosts to share data in any endianness that they choose, so long as they mark which one they are using. Both approaches have advantages: on the one hand, choosing a single endianness makes decoding easier, since software only needs to decode one format. On the other hand, allowing multiple endiannesses makes encoding easier, since software doesn’t need to convert data out of its native order; and also enables more efficient communication when the encoder and decoder share a single endianness, since neither needs to change the byte order. Most Internet standards take the first approach, and specify big-endian byte order. Many vendor originated formats simply use the byte order of the platform they originated on. Some other applications, notably X11, take the second approach.

UTF-16 can be written in big-endian or little-endian order. It permits a Byte Order Mark (BOM) of 2 bytes at the beginning of a string to denote its endianness. A similar 4 byte byte-order mark can be used with the rare encoding UTF-32.

[szerkesztés] Programozási példa a probléma bemutatására

A következő, C nyelven írt alkalmazás jól mutatja, hogy milyen veszélyeket rejt az eltérő endianitás:

#include <stdio.h>
#include <string.h>

int main(void)
{
  FILE *fp;

  /* Adatstruktura a peldahoz*/
  struct {
    char one[4];
    int  two;
    char three[4];
  } data;

  /* Az adatstruktura adatokkal valo feltoltese */
  strcpy(data.one, "foo");
  data.two = 0x01234567;
  strcpy(data.three, "bar");

  /* Iras a file-ba */
  fp = fopen("output", "wb");
  if (fp != NULL) {
    fwrite(&data, sizeof data, 1, fp);
    fclose(fp);
  }
}

A kódot egy i386 processzort használó gépen fordították le, majd és futtatták, majd egy Solaris SPARC64 gépen is fordították és futtatták, de a kinyomtatott eredmények eltérőek (a nyomtatások a hexdump programmal készültek).

i386 $ hexdump -C output 
00000000  66 6f 6f 00 67 45 23 01  62 61 72 00              |foo.gE#.bar.|
0000000c
sparc64 $ hexdump -C output
00000000  66 6f 6f 00 01 23 45 67  62 61 72 00              |foo..#Egbar.|
0000000c

[szerkesztés] Endianitás a kommunikációban

In general, the NUXI problem (also called the endian problem) is the problem of transferring data between computers with differing byte order. For example, the string "UNIX", packed with two bytes per 16-bit integer, might look like "NUXI" to a machine with a different byte order. The problem is caused by the difference in endianness. The problem was first discovered when porting an early version of Unix from PDP-11 (a middle-endian architecture) to an IBM Series 1 minicomputer (a big-endian architecture); upon startup, the computer output replaced the string "UNIX" with "NUXI".[forrás?]

The Internet Protocol defines a standard "big-endian" network byte order. This byte order is used for all numeric values in the packet headers and by many higher level protocols and file formats that are designed for use over IP.

The Berkeley sockets API defines a set of functions to convert 16- and 32-bit integers to and from network byte order: the htonl and htons functions convert 32-bit ("long") and 16-bit ("short") values respectively from host to network order; whereas the ntohl and ntohs functions convert from network to host order.

Serial devices also have bit-endianness: the bits in a byte can be sent little-endian (least significant bit first) or big-endian (most significant bit first). This decision is made in the very bottom of the data link layer of the OSI model.

[szerkesztés] Endianitás a dátum formátumoknál

Az endianitás egyszerűen bemutatható a különböző országok által használt dátum formátumokkal.

Az Amerikai Egyesült Államokban használt adatformátum a hónap; nap; év (pl.: "May 24th, 2006″, "5/24/2006″). Ez a középső a végén (middle-endian) sorrendet követi.

A legtöbb Óceániai, Dél-Amerikai és Európai ország (kivéve Svédországot és Magyarországot, ahol az ISO 8601 elterjedt), dátum formátum nap; hónap; év (pl.: "24th May, 2006″, "24/5/2006″, "24/5-2006″, "24.5.06″). Ez például egy kicsi a végén (little-endian) sorrend.

Több ország, többek között Kína és Japán, az ISO 8601 nemzetközi szabvány szerinti sorrendet használja a dátumoknál: év; hónap; nap (Pl.: "2006 May 24.", vagy, a leggyakoribb "2006-05-24″). Ez pedig a nagy a végén (big-endian) sorrend.

Az ISO 8601 elrendezési sémájára azt a javaslatot adja, hogy annak olyannak kell lennie, hogy azokat egy dátumra vonatkozó számítógépes rendezés lexikografikus sorrendbe, vagy szótár sorrendbe rendezze. Ez azt jelenti, hogy a rendezési algoritmus nem kezeli másként egy szövegben előforduló számot, mint magát a szöveg nem numerikus karaktereitet, így a dátumok rendezése időrendi sorrendet kell, hogy adjon. Meg kell jegyezni, hogy ennek működéséhez alapvetően szükséges, hogy az évet négy számjeggyel, a hónapot és a napot két számjeggyel ábrázolják. Ezért az egy számjegyű napokat és hónapokat ki kell egészíteni egy vezető nullával a következők szerint: ‘01′, ‘02′, … , ‘09′.

[szerkesztés] Endianitás a címzéseknél

A nyugaton használt postai címeket nagyrészben a "kicsi a végén" rendszerben aírják, a legkisebb összetevővel kezdik, (a címzett neve), majd a következnek a ház száma, az utca neve, a város neve, a régió, majd az ország. Néhány ázsiai ország (pl. Japán) a "kicsi a végén" rendszer helyett a "nagy a végén" rendszert használja: a cím az országgal kezdődik, mjd a régió, város, és a végén a címzett neve. Nálunk a keveret endianitást használják: címzett neve, város, utca, házszám, ország.

Az Internet domain név rendszere és az email címzés "kicsi a végén" rendszerű, követve a nyugati postai címzési rendszert. A UNIX (és más korszerű operációs rendszer) fájlrendszerének elérési útja (pathname) viszont "nagy a végén" rendszerű, alegmagasabb szintű könytárnév van legelöl. Az URL-ek, amelyek a két jelölési módot kombinálják, kevert endianitásúak, egy "kicsi a végén" endianitású host nevet követ egy "nagy a végén" andianitású elérési út, például:

protocol://organization.region.country/department/subdepartment/person

[szerkesztés] Háttér, érdekességek, etimológia

"Nagy a végén" módon ábrázolt számok könnyen olvahatók, ha programhibákat keresünk (debug). Néhányan azt gondolják, hogy ezek az emberek kevéssé intuitívok, mivel a "legjellemzőbb" byte van a "kisebb" címeken. Mások úgy gondolják, hogy ez kevéssé zavaró, mivel az ábrázolási mód hasonló, mint ahogyan a normál szöveget a számítógépben tárolják, éppen úgy mint egy nem-számítgépes szövegben (lásd később).

Little-endian numbers enjoy some slight computational advantages in that variables in memory do not have to be read and manipulated at their full widths. For example, a 32 bit variable in memory such as 00 00 00 4A can be read at the same address as either 8 bit (4A), 16 bit (00 4A), or 32 bit (00 00 00 4A) as long as its value stays within bounds. Big-endian cannot do this because the relative location of the least significant byte(s) change with the overall width of the variable. For example, 00 00 00 4A would become 00 when addressed as an 8 bit variable. Big-endian numbers are always corrupted if addressed as the wrong width unless the address is adjusted.

Az, hogy egyes emberek melyik ábrázolási módot kedvelik, az nagyobbrészt azon múlik, melyik ábrázolási módot tanulták meg először, illetve attól, hogy az illető mentális beállítódása milyen. Kifejezetten azoknak az embereknek az esetében, akiknek alacsony szintűek a számítógépes ismeretei, a legtöbb beszélt nyelv esetében, különösen a 100-nál nagyobb számok esetében, a "nagy a végén" módot használják. Magyarul például az mondjuk, hogy "háromszáz-huszonnégy", de nem mondjuk, hogy "négy és húsz és háromszáz". (A magyar példa kicsit erőltetettnek tűnhet, mivel mi amúgy sem teszünk kötőszót számok közé, de az angolban már más a helyzet: "three hundred twenty-four", nem pedig "four-and-twenty and three hundred".) [1] [2]. Meg kell azonban jegyezni, ellenpélda fentiekre a német nyelv és a holland nyelv, amelyek "kicsi a végén" rendszert használnak a számoknál 21 és 99 között, és kevert endianitást a nagyobb számoknál (pl. vierundzwanzig/vierentwintig (24, szószerint négy-és-húsz), és hundertvierundzwanzig (124, szószerint száz négy-és-húsz).

A hindu-arab számrendszert használják világszerte, és ebben a legjellemzőbb szám mindig balra van a kevésbé jellemzőnél (a legnagyobb nagyságrend van bal oldalon legelöl). Mivel balról jobbra írunk, ez a rendszer ezért "nagy a végén" módszer szerinti. Ennek számunkra különösebb jelentősége nincsen, azonban van néhány nyelv, ahol a számok olvasási sorrendje ellentétes az írásának sorrendjével, mint például a héber. Ekkor ugyanis meg kell szakítani a szöveg írási irányát (jobbról-balra) és a számokat elenkező irányban (balról-jobbra) kell írni. A németül vagy hollanul beszélők, ennek ellenére mégsem írják a kisebb számokat jobbról balra.

The choice of big-endian vs. little-endian was as arbitrary as the entire concept is, and has been the subject of flame wars. Emphasizing the futility of this argument, the very terms big-endian and little-endian were taken from the Big-Endians and Little-Endians of Jonathan Swift’s satiric novel Gulliver’s Travels, where in Lilliput and Blefuscu Gulliver finds two factions warring over which end of a boiled egg should be cracked open.

See the Endian FAQ, including the significant essay "On Holy Wars and a Plea for Peace" by Danny Cohen (1981).

Little-endian ordering has been used in compiling reverse dictionaries, such as rhyming dictionaries, where the entries begin, for example, with "a, aa, baa,..." and end, for example, with "...buzz, abuzz, fuzz." An actual example is the pronouncing dictionary for Cantonese jyt jɐm dziŋ duk dzi wɐi (ISBN 962-948-509-5) which begins with "a, ba, da, dza,..." and ends with "...tyt, tsyt, m̩, ŋ̩".


[szerkesztés] External links