Quali piattaforme hanno qualcosa di diverso dal char a 8 bit?

Di tanto in tanto, qualcuno su SO sottolinea che char(aka 'byte') non è necessariamente 8 bit .

Sembra che 8 bit charsia quasi universale. Avrei pensato che per le piattaforme tradizionali, è necessario disporre di un 8 bit charper garantirne la fattibilità sul mercato.

Sia ora che storicamente, quali piattaforme usano un charnon 8 bit, e perché dovrebbero differire dai "normali" 8 bit?

Quando si scrive codice e si pensa al supporto multipiattaforma (ad es. Per librerie di uso generale), che tipo di considerazione vale la pena prestare alle piattaforme con non-8-bit char?

In passato mi sono imbattuto in alcuni DSP Analog Devices per i quali charè 16 bit. I DSP sono un po 'un'architettura di nicchia, suppongo. (D'altra parte, all'epoca l'assemblatore con codice manuale batteva facilmente ciò che i compilatori C disponibili potevano fare, quindi non ho avuto molta esperienza con C su quella piattaforma.)

charè anche a 16 bit sui DSP C54x di Texas Instruments, presentati ad esempio in OMAP2. Ci sono altri DSP là fuori con 16 e 32 bit char. Penso di aver persino sentito parlare di un DSP a 24 bit, ma non ricordo cosa, quindi forse l'ho immaginato.

Un'altra considerazione è che i mandati POSIX CHAR_BIT == 8. Quindi, se stai usando POSIX, puoi assumerlo. Se in seguito qualcuno ha bisogno di trasferire il tuo codice su un'implementazione prossima di POSIX, è proprio per questo che ha le funzioni che usi ma di dimensioni diverse char, è la loro sfortuna.

In generale, tuttavia, penso che sia quasi sempre più facile aggirare il problema piuttosto che pensarci. Basta digitare CHAR_BIT. Se si desidera un tipo esatto di 8 bit, utilizzare int8_t. Il tuo codice non riuscirà a compilare rumorosamente su implementazioni che non ne forniscono una, invece di utilizzare silenziosamente una dimensione che non ti aspettavi. Per lo meno, se avessi affrontato un caso in cui avevo una buona ragione per assumerlo, lo affermerei.

Quando si scrive codice e si pensa al supporto multipiattaforma (ad es. Per librerie di uso generale), che tipo di considerazione vale la pena prestare alle piattaforme con caratteri non a 8 bit?

Non è così tanto che "vale la pena prendere in considerazione" qualcosa in quanto sta giocando secondo le regole. In C ++, ad esempio, lo standard dice che tutti i byte avranno "almeno" 8 bit. Se il tuo codice presuppone che i byte contengano esattamente 8 bit, stai violando lo standard.

Ora può sembrare sciocco - " ovviamente tutti i byte hanno 8 bit!", Ti sento dire. Ma molte persone molto intelligenti hanno fatto affidamento su ipotesi che non erano garanzie, e poi tutto si è rotto. La storia è piena di tali esempi.

Ad esempio, la maggior parte degli sviluppatori degli inizi degli anni '90 ipotizzava che un particolare ritardo di temporizzazione della CPU non operativo che richiedesse un numero fisso di cicli avrebbe richiesto un tempo di clock fisso, poiché la maggior parte delle CPU di consumo erano all'incirca equivalenti in termini di potenza. Sfortunatamente, i computer sono diventati più veloci molto rapidamente. Ciò ha generato l'ascesa di scatole con pulsanti "Turbo" - il cui scopo, ironicamente, era quello di rallentare il computer in modo che i giochi usando la tecnica del ritardo potessero essere giocati a una velocità ragionevole.

Un commentatore ha chiesto dove nello standard si dice che char deve avere almeno 8 bit. È nella sezione 5.2.4.2.1 . Questa sezione definisce CHAR_BITil numero di bit nell'entità indirizzabile più piccola e ha un valore predefinito di 8. Dice anche:

I loro valori definiti dall'implementazione devono essere uguali o maggiori in grandezza (valore assoluto) a quelli mostrati, con lo stesso segno.

Quindi qualsiasi numero uguale a 8 o superiore è adatto per la sostituzione mediante un'implementazione in CHAR_BIT.

Le macchine con architetture a 36 bit hanno byte a 9 bit. Secondo Wikipedia, le macchine con architetture a 36 bit includono:

• Digital Equipment Corporation PDP-6/10
• IBM 701/704/709/7090/7094
• UNIVAC 1103 / 1103A / 1105/1100/2200,

Alcuni dei quali sono a conoscenza:

• DEC PDP-10: caratteri variabili, ma il più delle volte a 7 bit impacchettati 5 per parola a 36 bit, oppure caratteri a 9 bit, 4 per parola
• Mainframe di Control Data (CDC-6400, 6500, 6600, 7600, Cyber ​​170, Cyber ​​176 ecc.) Caratteri a 6 bit, impacchettati 10 per parola a 60 bit.
• Mainframe Unisys: 9 bit / byte
• Windows CE: semplicemente non supporta affatto il tipo `char` - richiede invece 16 bit wchar_t

Non esiste un codice completamente portatile. :-)

Sì, potrebbero esserci varie dimensioni di byte / caratteri. Sì, potrebbero esserci implementazioni C / C ++ per piattaforme con valori molto insoliti di CHAR_BITe UCHAR_MAX. Sì, a volte è possibile scrivere codice che non dipende dalla dimensione del carattere.

Tuttavia, quasi ogni codice reale non è autonomo. Ad esempio, potresti scrivere un codice che invia messaggi binari alla rete (il protocollo non è importante). È possibile definire strutture che contengono campi necessari. Di quanto devi serializzarlo. La semplice copia binaria di una struttura in un buffer di output non è portatile: generalmente non si conosce né l'ordine dei byte per la piattaforma, né l'allineamento dei membri della struttura, quindi la struttura contiene solo i dati, ma non descrive il modo in cui i dati devono essere serializzati .

Ok. È possibile eseguire trasformazioni dell'ordine dei byte e spostare i membri della struttura (ad esempio uint32_to simili) utilizzando memcpynel buffer. Perché memcpy? Perché ci sono molte piattaforme in cui non è possibile scrivere a 32 bit (16 bit, 64 bit - nessuna differenza) quando l'indirizzo di destinazione non è allineato correttamente.

Quindi, hai già fatto molto per raggiungere la portabilità.

E ora l'ultima domanda. Abbiamo un buffer. I dati da esso inviati vengono inviati alla rete TCP / IP. Tale rete assume byte a 8 bit. La domanda è: di che tipo dovrebbe essere il buffer? Se i tuoi caratteri sono a 9 bit? Se sono a 16 bit? 24? Forse ogni carattere corrisponde a un byte a 8 bit inviato alla rete e vengono utilizzati solo 8 bit? O forse più byte di rete sono impacchettati in caratteri a 24/16/9 bit? Questa è una domanda, ed è difficile credere che esista un'unica risposta adatta a tutti i casi. Molte cose dipendono dall'implementazione del socket per la piattaforma di destinazione.

Quindi, di cosa sto parlando. Di solito il codice può essere relativamente facilmente trasportabile in una certa misura . È molto importante farlo se si prevede di utilizzare il codice su piattaforme diverse. Tuttavia, migliorare la portabilità oltre tale misura è una cosa che richiede molto sforzo e spesso dà poco , poiché il codice reale dipende quasi sempre da altro codice (implementazione del socket nell'esempio sopra). Sono sicuro che per circa il 90% della capacità del codice di lavorare su piattaforme con byte diversi da 8 bit è quasi inutile, poiché utilizza un ambiente associato a 8 bit. Basta controllare la dimensione dei byte ed eseguire l'asserzione del tempo di compilazione. Quasi sicuramente dovrai riscrivere molto per una piattaforma molto insolita.

Ma se il tuo codice è altamente "autonomo" - perché no? Puoi scriverlo in un modo che consenta dimensioni di byte diverse.

Sembra che sia ancora possibile acquistare un IM6100 (ovvero un PDP-8 su un chip) da un magazzino. Questa è un'architettura a 12 bit.

Molti chip DSP hanno 16 o 32 bit char. TI rende ordinariamente tali chip per esempio .

I linguaggi di programmazione C e C ++, ad esempio, definiscono il byte come "unità di dati indirizzabili abbastanza grande da contenere qualsiasi membro del set di caratteri di base dell'ambiente di esecuzione" (clausola 3.6 dello standard C). Poiché il tipo di dati integrale C char deve contenere almeno 8 bit (clausola 5.2.4.2.1), un byte in C è almeno in grado di contenere 256 valori diversi. Varie implementazioni di C e C ++ definiscono un byte come 8, 9, 16, 32 o 36 bit

Citato da http://en.wikipedia.org/wiki/Byte#History

Non sono sicuro di altre lingue però.

http://en.wikipedia.org/wiki/IBM_7030_Stretch#Data_Formats

Definisce un byte su quella macchina come lunghezza variabile

La famiglia DEC PDP-8 aveva una parola a 12 bit sebbene di solito si usasse ASCII a 8 bit per l'output (principalmente su un tipo di Teletype). Tuttavia, c'era anche un codice di carattere a 6 bit che ti consentiva di codificare 2 caratteri in una singola parola a 12 bit.

Per uno, i caratteri Unicode sono più lunghi di 8 bit. Come qualcuno ha menzionato in precedenza, la specifica C definisce i tipi di dati in base alle loro dimensioni minime. Utilizzare sizeofe i valori in limits.hse si desidera interrogare i tipi di dati e scoprire esattamente quali dimensioni sono per la configurazione e l'architettura.

Per questo motivo, provo ad attenermi a tipi di dati come uint16_tquando ho bisogno di un tipo di dati di una determinata lunghezza di bit.

Modifica: scusa, inizialmente ho letto male la tua domanda.

La specifica C afferma che un charoggetto è "abbastanza grande da contenere qualsiasi membro del set di caratteri di esecuzione". limits.helenca una dimensione minima di 8 bit, ma la definizione lascia charaperta la dimensione massima .

Pertanto, a charè almeno lungo quanto il carattere più grande del set di esecuzione dell'architettura (in genere arrotondato per eccesso al limite di 8 bit più vicino). Se la tua architettura ha codici operativi più lunghi, le chardimensioni potrebbero essere più lunghe.

Storicamente, il codice operativo della piattaforma x86 era lungo un byte, quindi charinizialmente era un valore di 8 bit. Le attuali piattaforme x86 supportano i codici operativi più lunghi di un byte, ma charsono mantenuti a 8 bit di lunghezza poiché è quello a cui sono condizionati i programmatori (e i grandi volumi del codice x86 esistente).

Quando si pensa al supporto multipiattaforma, sfruttare i tipi definiti in stdint.h. Se si utilizza (ad esempio) un uint16_t, allora si può essere sicuri che questo valore è un valore a 16 bit senza segno su qualsiasi architettura, se corrispondente valore a 16 bit a una char, short, int, o qualcos'altro. Gran parte del duro lavoro è già stato fatto dalle persone che hanno scritto il tuo compilatore / librerie standard.

Se devi conoscere la dimensione esatta di a charperché stai eseguendo una manipolazione hardware di basso livello che lo richiede, di solito utilizzo un tipo di dati abbastanza grande da contenere un charsu tutte le piattaforme supportate (di solito 16 bit è sufficiente) ed eseguire il valore attraverso una convert_to_machine_charroutine quando ho bisogno della rappresentazione esatta della macchina. In questo modo, il codice specifico della piattaforma è limitato alla funzione di interfaccia e il più delle volte posso usare un normale uint16_t.

che tipo di considerazione vale la pena dare alle piattaforme con caratteri non a 8 bit?

si verificano numeri magici, ad es. quando si sposta;

la maggior parte di questi può essere gestita semplicemente usando CHAR_BIT e ad esempio UCHAR_MAX invece di 8 e 255 (o simili).

speriamo che la tua implementazione li definisca :)

quelli sono i problemi "comuni" .....

un altro problema indiretto è che hai:

struct xyz {
   uchar baz;
   uchar blah;
   uchar buzz; 
}

questo potrebbe "solo" prendere (nel migliore dei casi) 24 bit su una piattaforma, ma potrebbe richiedere ad esempio 72 bit altrove .....

se ogni uchar contenesse "bit flags" e ogni uchar avesse solo 2 bit o flag "significativi" che stavi attualmente utilizzando, e li organizzassi solo in 3 uchar per "chiarezza", allora potrebbe essere relativamente "più dispendioso" ad es. una piattaforma con uchar a 24 bit .....

niente campi di bit non possono risolvere, ma hanno altre cose a cui fare attenzione ....

in questo caso, solo un singolo enum potrebbe essere un modo per ottenere il numero intero "più piccolo" di cui hai effettivamente bisogno ....

forse non è un vero esempio, ma cose come questa mi "mordono" durante il porting / giocando con un po 'di codice .....

solo il fatto che se un uchar è tre volte più grande di quello che è "normalmente" previsto, 100 di tali strutture potrebbero sprecare molta memoria su alcune piattaforme ..... dove "normalmente" non è un grosso problema .... .

quindi le cose possono ancora essere "rotte" o in questo caso "sprecare molta memoria molto rapidamente" a causa del presupposto che un uchar sia "non molto dispendioso" su una piattaforma, rispetto alla RAM disponibile, che su un'altra piattaforma ... ..

il problema potrebbe essere più evidente, ad esempio anche per gli ints o altri tipi, ad esempio hai una struttura che ha bisogno di 15 bit, quindi lo inserisci in un int, ma su un'altra piattaforma un int è di 48 bit o altro .... .

"normalmente" potresti dividerlo in 2 uchar, ma ad esempio con un uchar a 24 bit ne avresti bisogno solo uno .....

quindi un enum potrebbe essere una migliore soluzione "generica" ​​....

dipende da come stai accedendo a quei bit :)

quindi, potrebbero esserci "difetti di progettazione" che alzano la testa ... anche se il codice potrebbe ancora funzionare / funzionare bene indipendentemente dalle dimensioni di un uchar o uint ...

ci sono cose come queste a cui prestare attenzione, anche se non ci sono "numeri magici" nel tuo codice ...

spero che questo abbia senso :)

Ints erano 16 bit (pdp11, ecc.). Passare alle architetture a 32 bit è stato difficile. Le persone stanno migliorando: quasi nessuno suppone che un puntatore si adatti più a lungo (non è vero?). O offset di file, o timestamp, o ...

I caratteri a 8 bit sono già un po 'anacronistici. Abbiamo già bisogno di 32 bit per contenere tutti i set di caratteri del mondo.