Welche Plattformen haben etwas anderes als 8-Bit-Zeichen?

Hin und wieder weist jemand auf SO darauf hin, dass char(auch bekannt als "Byte") nicht unbedingt 8 Bits sind .

Es scheint, dass 8-Bit charfast universell ist. Ich hätte gedacht, dass es für Mainstream-Plattformen notwendig ist, ein 8-Bit charzu haben, um seine Lebensfähigkeit auf dem Markt sicherzustellen.

Welche Plattformen verwenden jetzt und in der Vergangenheit eine char, die nicht 8 Bit beträgt, und warum sollten sie sich von den "normalen" 8 Bit unterscheiden?

Welche Überlegungen sollten beim Schreiben von Code und beim Nachdenken über plattformübergreifende Unterstützung (z. B. für allgemein verwendete Bibliotheken) Plattformen mit Nicht-8-Bit-Funktionen berücksichtigt werden char?

In der Vergangenheit bin ich auf einige DSPs von Analog Devices gestoßen, für die char16 Bit verfügbar sind. DSPs sind wohl eine Art Nischenarchitektur. (Andererseits übertraf der handcodierte Assembler zu dieser Zeit leicht die Möglichkeiten der verfügbaren C-Compiler, sodass ich auf dieser Plattform nicht wirklich viel Erfahrung mit C gesammelt habe.)

charist auch 16 Bit auf den Texas Instruments C54x DSPs, die zum Beispiel in OMAP2 aufgetaucht sind. Es gibt andere DSPs mit 16 und 32 Bit char. Ich glaube, ich habe sogar von einem 24-Bit-DSP gehört, aber ich kann mich nicht erinnern, was, also habe ich es mir vielleicht vorgestellt.

Eine weitere Überlegung ist, dass POSIX Mandate CHAR_BIT == 8. Wenn Sie also POSIX verwenden, können Sie davon ausgehen. Wenn jemand später Ihren Code auf eine nahezu Implementierung von POSIX portieren muss, hat dies zufällig die von Ihnen verwendeten Funktionen, aber eine andere Größe char, das ist sein Pech.

Im Allgemeinen denke ich jedoch, dass es fast immer einfacher ist, das Problem zu umgehen, als darüber nachzudenken. Geben Sie einfach ein CHAR_BIT. Wenn Sie einen genauen 8-Bit-Typ wünschen, verwenden Sie int8_t. Ihr Code kann bei Implementierungen, die keine bereitstellen, geräuschvoll kompiliert werden, anstatt stillschweigend eine Größe zu verwenden, die Sie nicht erwartet haben. Zumindest würde ich es behaupten, wenn ich auf einen Fall stoßen würde, in dem ich einen guten Grund hatte, ihn anzunehmen.

Welche Überlegungen sollten beim Schreiben von Code und beim Nachdenken über plattformübergreifende Unterstützung (z. B. für Bibliotheken mit allgemeiner Verwendung) Plattformen mit Nicht-8-Bit-Zeichen berücksichtigt werden?

Es ist nicht so sehr, dass es sich lohnt, über etwas nachzudenken, sondern dass es sich an die Regeln hält. In C ++ sagt der Standard beispielsweise, dass alle Bytes "mindestens" 8 Bits haben. Wenn Ihr Code davon ausgeht, dass Bytes genau 8 Bit haben, verstoßen Sie gegen den Standard.

Das mag jetzt albern erscheinen - " Natürlich haben alle Bytes 8 Bits!", Höre ich Sie sagen. Aber viele sehr kluge Leute haben sich auf Annahmen verlassen, die keine Garantien waren, und dann ist alles kaputt gegangen. Die Geschichte ist voll von solchen Beispielen.

Zum Beispiel gingen die meisten Entwickler Anfang der 90er Jahre davon aus, dass eine bestimmte No-Op-CPU-Zeitverzögerung, die eine feste Anzahl von Zyklen benötigt, eine feste Taktzeit in Anspruch nehmen würde, da die meisten Consumer-CPUs in etwa gleich leistungsfähig waren. Leider wurden Computer sehr schnell schneller. Dies führte zur Entstehung von Boxen mit "Turbo" -Tasten - deren Zweck ironischerweise darin bestand, den Computer zu verlangsamen, damit Spiele mit der Zeitverzögerungstechnik mit einer angemessenen Geschwindigkeit gespielt werden konnten.

Ein Kommentator fragte, wo im Standard steht, dass char mindestens 8 Bits haben muss. Es ist in Abschnitt 5.2.4.2.1 . Dieser Abschnitt definiert CHAR_BITdie Anzahl der Bits in der kleinsten adressierbaren Entität und hat einen Standardwert von 8. Außerdem heißt es:

Ihre implementierungsdefinierten Werte müssen gleich oder größer (absoluter Wert) sein als die angegebenen Werte mit demselben Vorzeichen.

Daher ist jede Zahl gleich 8 oder höher für die Substitution durch eine Implementierung in geeignet CHAR_BIT.

Maschinen mit 36-Bit-Architekturen haben 9-Bit-Bytes. Laut Wikipedia gehören zu Maschinen mit 36-Bit-Architekturen :

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

Einige davon sind mir bekannt:

• DEC PDP-10: variabel, aber meistens 7-Bit-Zeichen, gepackt mit 5 pro 36-Bit-Wort oder 9-Bit-Zeichen, 4 pro Wort
• Steuerdaten-Mainframes (CDC-6400, 6500, 6600, 7600, Cyber ​​170, Cyber ​​176 usw.) 6-Bit-Zeichen, 10 pro 60-Bit-Wort.
• Unisys-Mainframes: 9 Bit / Byte
• Windows CE: unterstützt den Typ "char" einfach überhaupt nicht - erfordert stattdessen 16-Bit-wchar_t

Es gibt keinen vollständig portablen Code. :-)

Ja, es kann verschiedene Byte- / Zeichengrößen geben. Ja, es gibt möglicherweise C / C ++ - Implementierungen für Plattformen mit sehr ungewöhnlichen Werten von CHAR_BITund UCHAR_MAX. Ja, manchmal ist es möglich, Code zu schreiben, der nicht von der Zeichengröße abhängt.

Fast jeder echte Code ist jedoch nicht eigenständig. Beispielsweise schreiben Sie möglicherweise einen Code, der Binärnachrichten an das Netzwerk sendet (Protokoll ist nicht wichtig). Sie können Strukturen definieren, die erforderliche Felder enthalten. Dann müssen Sie es serialisieren. Nur das binäre Kopieren einer Struktur in einen Ausgabepuffer ist nicht portierbar: Im Allgemeinen kennen Sie weder die Bytereihenfolge für die Plattform noch die Ausrichtung der Strukturelemente, sodass die Struktur nur die Daten enthält, aber nicht beschreibt, wie die Daten serialisiert werden sollen .

OK. Sie können Transformationen der Bytereihenfolge durchführen und die Strukturelemente (z. B. uint32_toder ähnliches) mithilfe memcpyin den Puffer verschieben. Warum memcpy? Weil es viele Plattformen gibt, auf denen es nicht möglich ist, 32-Bit (16-Bit, 64-Bit - kein Unterschied) zu schreiben, wenn die Zieladresse nicht richtig ausgerichtet ist.

Sie haben also bereits viel getan, um Portabilität zu erreichen.

Und jetzt die letzte Frage. Wir haben einen Puffer. Die Daten davon werden an das TCP / IP-Netzwerk gesendet. Ein solches Netzwerk nimmt 8-Bit-Bytes an. Die Frage ist: Von welchem ​​Typ sollte der Puffer sein? Wenn Ihre Zeichen 9-Bit sind? Wenn sie 16-Bit sind? 24? Vielleicht entspricht jedes Zeichen einem 8-Bit-Byte, das an das Netzwerk gesendet wird, und es werden nur 8 Bit verwendet? Oder sind mehrere Netzwerkbytes in 24/16/9-Bit-Zeichen gepackt? Das ist eine Frage, und es ist kaum zu glauben, dass es eine einzige Antwort gibt, die in alle Fälle passt. Viele Dinge hängen von der Socket-Implementierung für die Zielplattform ab.

Also, wovon ich spreche. Normalerweise kann Code bis zu einem gewissen Grad relativ leicht portierbar gemacht werden . Dies ist sehr wichtig, wenn Sie den Code auf verschiedenen Plattformen verwenden möchten. Die Verbesserung der Portabilität über diese Maßnahme hinaus erfordert jedoch viel Aufwand und ist häufig wenig sinnvoll , da der tatsächliche Code fast immer von anderem Code abhängt (Socket-Implementierung im obigen Beispiel). Ich bin sicher, dass für etwa 90% des Codes die Fähigkeit, auf Plattformen mit anderen Bytes als 8-Bit zu arbeiten, fast nutzlos ist, da eine Umgebung verwendet wird, die an 8-Bit gebunden ist. Überprüfen Sie einfach die Bytegröße und führen Sie die Bestätigung der Kompilierungszeit durch. Für eine höchst ungewöhnliche Plattform müssen Sie mit ziemlicher Sicherheit viel umschreiben.

Aber wenn Ihr Code sehr "eigenständig" ist - warum nicht? Sie können es so schreiben, dass unterschiedliche Bytegrößen möglich sind.

Es scheint, dass Sie immer noch einen IM6100 (dh einen PDP-8 auf einem Chip) aus einem Lager kaufen können . Das ist eine 12-Bit-Architektur.

Viele DSP-Chips haben 16- oder 32-Bit char. TI stellt solche Chips beispielsweise routinemäßig her .

Die Programmiersprachen C und C ++ definieren beispielsweise Byte als "adressierbare Dateneinheit, die groß genug ist, um ein Mitglied des Grundzeichensatzes der Ausführungsumgebung aufzunehmen" (Abschnitt 3.6 des C-Standards). Da der Datentyp C char Integral mindestens 8 Bits enthalten muss (Abschnitt 5.2.4.2.1), kann ein Byte in C mindestens 256 verschiedene Werte enthalten. Verschiedene Implementierungen von C und C ++ definieren ein Byte als 8, 9, 16, 32 oder 36 Bit

Zitiert aus http://en.wikipedia.org/wiki/Byte#History

Ich bin mir jedoch nicht sicher über andere Sprachen.

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

Definiert ein Byte auf diesem Computer mit variabler Länge

Die DEC PDP-8-Familie hatte ein 12-Bit-Wort, obwohl Sie normalerweise 8-Bit-ASCII für die Ausgabe verwendeten (meistens auf einem Teletyp). Es gab jedoch auch einen 6-BIT-Zeichencode, mit dem Sie 2 Zeichen in einem einzelnen 12-Bit-Wort codieren konnten.

Zum einen sind Unicode-Zeichen länger als 8 Bit. Wie bereits erwähnt, definiert die C-Spezifikation Datentypen anhand ihrer Mindestgröße. Verwenden Sie sizeofund die Werte in, limits.hwenn Sie Ihre Datentypen abfragen und genau herausfinden möchten, welche Größe sie für Ihre Konfiguration und Architektur haben.

Aus diesem Grund versuche ich, mich an Datentypen zu halten, beispielsweise uint16_twenn ich einen Datentyp mit einer bestimmten Bitlänge benötige.

Edit: Sorry, ich habe deine Frage zunächst falsch verstanden.

Die C-Spezifikation besagt, dass ein charObjekt "groß genug ist, um ein Mitglied des Ausführungszeichensatzes zu speichern". limits.hlistet eine minimale Größe von 8 Bit auf, aber die Definition lässt die maximale Größe eines charoffen.

Somit ist das a charmindestens so lang wie das größte Zeichen aus dem Ausführungssatz Ihrer Architektur (normalerweise auf die nächste 8-Bit-Grenze aufgerundet). Wenn Ihre Architektur längere Opcodes enthält, ist Ihre charGröße möglicherweise länger.

In der Vergangenheit war der Opcode der x86-Plattform ein Byte lang, also charzunächst ein 8-Bit-Wert. Aktuelle x86-Plattformen unterstützen Opcodes, die länger als ein Byte sind, aber die charLänge beträgt 8 Bit, da Programmierer (und die großen Mengen des vorhandenen x86-Codes) darauf konditioniert sind.

Nutzen Sie die in definierten Typen, wenn Sie über die Unterstützung mehrerer Plattformen nachdenken stdint.h. Wenn Sie (zum Beispiel) ein uint16_t verwenden, dann können Sie sicher sein , dass dieser Wert ist ein unsigned 16-Bit - Wert aus welcher Architektur, ob die 16-Bit - Wert entspricht einen char, short, int, oder etwas anderes. Die meiste harte Arbeit wurde bereits von den Leuten geleistet, die Ihre Compiler- / Standardbibliotheken geschrieben haben.

Wenn Sie die genaue Größe von a kennen müssen, charweil Sie eine Hardwaremanipulation auf niedriger Ebene durchführen, die dies erfordert, verwende ich normalerweise einen Datentyp, der groß genug ist, um a charauf allen unterstützten Plattformen zu speichern (normalerweise sind 16 Bit ausreichend) und auszuführen der Wert durch eine convert_to_machine_charRoutine, wenn ich die genaue Maschinendarstellung brauche. Auf diese Weise ist der plattformspezifische Code auf die Schnittstellenfunktion beschränkt und meistens kann ich einen normalen Code verwenden uint16_t.

Welche Überlegung lohnt sich für Plattformen mit Nicht-8-Bit-Zeichen?

magische Zahlen treten zB beim Verschieben auf;

Die meisten davon können ganz einfach mit CHAR_BIT und z. B. UCHAR_MAX anstelle von 8 und 255 (oder ähnlichem) behandelt werden.

hoffentlich definiert deine Implementierung diese :)

das sind die "gemeinsamen" Probleme .....

Ein weiteres indirektes Problem ist, dass Sie Folgendes haben:

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

Dies kann "nur" (im besten Fall) 24 Bit auf einer Plattform dauern, aber zB 72 Bit an anderer Stelle .....

Wenn jeder Uchar "Bit-Flags" enthielt und jeder Uchar nur 2 "signifikante" Bits oder Flags hatte, die Sie gerade verwendeten, und Sie sie aus "Klarheit" nur in 3 Uchars organisiert haben, ist dies möglicherweise relativ "verschwenderischer", z eine Plattform mit 24-Bit-Uchars .....

Nichts, was Bitfelder nicht lösen können, aber sie müssen auf andere Dinge achten ...

In diesem Fall kann nur eine einzige Aufzählung eine Möglichkeit sein, die "kleinste" Ganzzahl zu erhalten, die Sie tatsächlich benötigen.

vielleicht kein wirkliches Beispiel, aber solche Sachen "haben" mich beim Portieren / Spielen mit Code "gebissen" .....

Nur die Tatsache, dass, wenn ein Uchar dreimal so groß ist wie "normalerweise" erwartet, 100 solcher Strukturen auf einigen Plattformen viel Speicher verschwenden könnten ... wo "normalerweise" keine große Sache ist ... .

Daher können die Dinge immer noch "kaputt" sein oder in diesem Fall "sehr schnell viel Speicher verschwenden", da angenommen wird, dass ein Ukar auf einer Plattform im Verhältnis zum verfügbaren RAM "nicht sehr verschwenderisch" ist als auf einer anderen Plattform ... ..

Das Problem könnte z. B. auch für Ints oder andere Typen auftreten, z. B. wenn Sie eine Struktur haben, die 15 Bit benötigt, also stecken Sie sie in ein Int, aber auf einer anderen Plattform ist ein Int 48 Bit oder was auch immer .... .

"normal" könnten Sie es in 2 Uchars aufteilen, aber zB mit einem 24-Bit-Uchar würden Sie nur einen brauchen .....

Eine Aufzählung könnte also eine bessere "generische" Lösung sein ...

hängt davon ab, wie Sie auf diese Bits zugreifen :)

Es kann also zu "Designfehlern" kommen, die ihren Kopf aufrichten ... selbst wenn der Code ungeachtet der Größe eines Ukar oder Uint immer noch einwandfrei funktioniert / läuft ...

Es gibt solche Dinge, auf die Sie achten müssen, obwohl Ihr Code keine "magischen Zahlen" enthält ...

hoffe das macht Sinn :)

Ints waren früher 16 Bit (pdp11 usw.). Es war schwierig, auf 32-Bit-Architekturen umzusteigen. Die Leute werden besser: Kaum jemand geht davon aus, dass ein Zeiger mehr passt (stimmt das nicht?). Oder Datei-Offsets oder Zeitstempel oder ...

8-Bit-Zeichen sind bereits ein Anachronismus. Wir benötigen bereits 32 Bit, um alle Zeichensätze der Welt aufzunehmen.