Little Endian ha vinto?

34

Durante l'insegnamento recente sulla battaglia tra Big e Little Endian, uno studente ha chiesto se fosse stata risolta e mi sono reso conto che non lo sapevo. Guardando l' articolo di Wikipedia , sembra che le attuali coppie di sistemi operativi / architetture più popolari utilizzino Little Endian ma che Internet Protocol specifichi Big Endian per il trasferimento di valori numerici nelle intestazioni dei pacchetti. Sarebbe un buon riassunto dello stato attuale? Le attuali schede di rete o CPU forniscono supporto hardware per la commutazione dell'ordine dei byte?

— Ellen Spertus
fonte

25

Direi che non è tanto vinto quanto smesso di importare. ARM che costituisce fondamentalmente tutto il mercato mobile è bi-endian (oh, l'eresia!). Nel senso che x86 fondamentalmente "ha vinto" il mercato desktop, suppongo che si possa dire che il piccolo endian ha vinto, ma penso che data la profondità complessiva del codice (superficiale) e l'astrazione (molte) di molte applicazioni di oggi, è molto meno un problema di era una volta. Non ricordo l'endianità che mi è venuta in mente durante la mia lezione di Computer Architecture.

Sospetto che molti sviluppatori non siano nemmeno a conoscenza dell'endianness o del perché sia importante. Perché per la stragrande maggioranza (e intendo la stragrande maggioranza) è assolutamente irrilevante per il loro ambiente di lavoro quotidiano. Questo era diverso 30 anni fa, quando tutti stavano programmando un codice molto più vicino al metal, invece di manipolare i file di testo su uno schermo in modi fantasiosi e drammatici.

Il mio sospetto generale è che la programmazione orientata agli oggetti sia stata l'inizio della fine della cura dell'endianità poiché gli strati di accesso e astrazione in un buon sistema OO nascondono all'utente i dettagli dell'implementazione. Poiché l'implementazione include l'endianità, le persone si sono abituate a non essere un fattore esplicito.

Addendum: zxcdw ha menzionato la portabilità come preoccupazione. Tuttavia, che cosa è sorto con una vendetta negli ultimi 20 anni? Linguaggi di programmazione basati su macchine virtuali. Sicuramente l'endianness della macchina virtuale potrebbe essere importante, ma può essere reso molto coerente per quell'unica lingua al punto in cui è fondamentalmente un non-problema. Solo gli implementatori di macchine virtuali dovrebbero anche preoccuparsi dell'endianità dal punto di vista della portabilità.

— Ingegnere mondiale
fonte

2

Ci sono ancora molti domini molto rilevanti in cui è importante, ad esempio quando si scrive qualsiasi forma di codice portatile. Infatti, dove probabilmente non importa è quando si scrive codice non portatile che è legato a una piattaforma.

— zxcdw,

@zxcdw che ci porta direttamente all'esercito di linguaggi di macchine virtuali là fuori ... Non ci avevo pensato.

— Ingegnere mondiale,

Il tuo addendum non è del tutto vero (e non sono nemmeno d'accordo con @zxcdw): l'endianness è importante solo quando si traduce tra interi multibyte e flussi di byte, e diventa un problema quando viene fatto in modo implicito e varia tra le piattaforme. La maggior parte dei linguaggi moderni (basati su VM o meno) raggiungono la portabilità facendola raramente (con numeri interi come tipo di dati opaco), e quindi hanno l'endianità specificata indipendentemente dalla piattaforma o scelta esplicitamente dal programmatore.

— Michael Borgwardt,

2

@MichaelBorgwardt

— Ingegnere mondiale

2

@zxcdw - anche in assemblatore, non è sempre necessario conoscere l'ordine endian. Le costanti, ad esempio, non devono essere specificate un byte alla volta. La situazione è in qualche modo simile a un certo stile di serializzazione in C: x & 0xFFti dà sempre il byte meno significativo indipendentemente dall'ordinamento degli endiani (supponendo che i tuoi byte siano 8 bit ciascuno) perché hai specificato i bit che ti interessano dal loro valore, non la loro posizione relativa nella memoria.

— Steve314,

4

Gli endian contano davvero solo quando si trasferiscono sistemi di dati binari.

Con l'avanzamento della velocità del processore (e un costo di archiviazione molto più basso) le interfacce dei dati binari stanno diventando più rare, quindi non le notate a livello di applicazione. Stai utilizzando un formato di trasferimento testuale (XML / JSON) o stai utilizzando l'astrazione del livello dati che si occupa della traduzione per te (quindi non ti accorgi nemmeno che esiste una traduzione).

Ma quando si codifica a livello di dati binari, si nota ed è molto importante. Ad esempio, quando ho lavorato presso VERITAS (ora Symantec), stavo costruendo un software che veniva creato su 25 piattaforme hardware diverse (non solo big / little endian ce ne sono altri tipi).

— Martin York
fonte

I miei studenti hanno anche sviluppato telefoni cellulari e utilizzato il cloud computing, quindi sanno che il mondo non è PC e Mac.

— Ellen Spertus,

@Loki: è possibile serializzare e deserializzare senza conoscere l'endian della macchina. Hai solo bisogno di conoscere l'ordinamento in byte dei dati nei file / flussi / qualunque cosa. Ad esempio, (char) (x & 0xFF)in C ti dà il byte meno significativo indipendentemente dai problemi dell'endian, supponendo solo che un byte sia 8 bit. Ho progettato formati di file binari senza conoscere le macchine su cui verrebbe eseguito il software - fondamentalmente ho scelto un ordinamento endian per il formato di file senza preoccuparmi dell'hardware.

— Steve314,

@espertus: certo possibile.

— Martin York,

1

@ Steve314: Sì certo che puoi. Quando stai lavorando al "Binary Data Layer" puoi escogitare qualsiasi schema tu voglia serializzare i tuoi dati e non è difficile escogitare schemi che siano portabili. Anche se personalmente non mi preoccuperei di reinventare una ruota che è stata costruita e ben collaudata dagli anni '60. Cerca ` h2nl e famiglia. questa famiglia di funzioni offre un modo portatile (standard) di fare le cose ottimali per la tua piattaforma.

— Martin York,

4

No, nessuno ha vinto. Noi come specie non siamo riusciti a standardizzare l'ordine in cui immagazziniamo i nostri byte, insieme alla direzione che scriviamo e al lato della strada su cui guidiamo.

Di conseguenza, chiunque desideri trasferire dati tra due diversi sistemi su una rete o in un file, ha solo una probabilità del 50% circa che la versione iniziale ragionevole del proprio codice di dumping dei dati sia corretta nel proprio ambiente e anche se funziona , ha una probabilità del 50% di lavorare presso i propri clienti.

Per far fronte a questo è necessario cercare funzioni specifiche della piattaforma con nomi come "htonl" nelle intestazioni con nomi ovviamente risalenti agli anni '70 come "arpa / inet.h", perché la situazione non è migliorata da allora e probabilmente non lo farà mai .

— Andrew Wagner
fonte

10

risulta che abbiamo standardizzato - invece di inviare 4 byte per rappresentare un numero intero, inviamo un blocco di testo formattato con testo di intestazione speciale, parentesi angolari, parole chiave e una rappresentazione ASCII di quei 4 byte. L'estremità ricevente quindi analizza la formattazione per ottenere il testo intero e lo converte in 4 byte. Questo si chiama progresso, mi viene detto :-)

— gbjbaanb

$ aptitude cerca xml | wc -l 677

— Andrew Wagner,

1

Non c'è ancora consenso:

La maggior parte dei sistemi informatici più grandi (server / desktop / laptop) attualmente utilizza architetture little-endian
La maggior parte dei computer più piccoli (tablet / telefoni) utilizza un'architettura di processore indipendente dall'endianità, ma esegue sistemi operativi che utilizzano un ordine little-endian

Quindi a livello hardware, LE è molto più comune. Ma:

La maggior parte delle comunicazioni tra computer avviene tramite protocolli che specificano l'ordine big-endian
Una parte molto ampia del software mondiale viene eseguita su una piattaforma virtuale che passa per impostazione predefinita all'ordine big-endian ogni volta che i dati vengono scritti su un archivio esterno.

Entrambi gli ordini saranno con noi per il prossimo futuro.

— Jules
fonte

La maggior parte dei sistemi più grandi (ovvero "big iron") è tipicamente big-endian. Cioè, i cosiddetti sistemi mini o mainframe (che costituiscono un'enorme quantità di elaborazione back-end, a cui la maggior parte di noi non importa).

@jdv Ma la maggior parte dei sistemi informatici più grandi sono macchine x86-64 di piccole dimensioni e quindi le prestazioni contano.

— user877329

Non credo che nessuno possa affermare con forza che l'endianità sia qualcosa di più della convenienza da parte dei progettisti dell'architettura (per tutto ciò che vogliono ottenere). All'epoca in cui ho fatto quell'antico commento, il grande ferro era BE. Ma questo non è perché è BE, ma perché l'architettura sembra essere così.