Am Anfang war das Wort

Hans lieferte mir den Aufhänger für den heutigen Artikel, der sich auch mit Prozessorarchitekturen beschäftigt. Nämlich die Frage wie man 16 Bits in der Informationstechnik bezeichnet. Schon mal der Ansatz wie Hans diese Frage löst ist interessant. Ich würde in Google Books nachschauen oder in meinem Bücherregal. Hans stellt die Frage in einem Forum, was angesichts einer Generation die mit der x86 Architektur aufgewachsenen ist und vielen Softwerkern, die meinen die Bezeichnungen in ihrer Programmiersprache wären Standardausdrücke, in etwa so ist als wenn man auf einem mittelalterlichen Markt fragt „Ist die rothaarige Frau eine Hexe?„.

Also welche standardisierten Ausdrücke gibt es in der Informationstechnik? Nun als erstes gibt es mal das Bit. Ein Bit ist die kleinste Einheit, die gespeichert werden kann. Bei den meisten Computern ist es aber nicht die kleinste Einheit die sie ansprechen können, außer sie haben Bitmanipulationsbefehle. Doch Speicherbausteine waren sehr lange bitweise organisiert. Früher war das sogar noch zu sehen. Bei Ringkernspeichern entsprach das genau einem Eisenkern. Die bitweise Organisation sieht man heute noch manchmal in den Anzahl der Speicherbausteine auf DIMMs, auch wenn es hier noch die Organisation in 4 und 16 Bit Einheiten gibt die gängiger ist, weil man so weniger Chips braucht. (16 oder 4 für die heutigen DIMM die 64 Bit Datenbusse haben anstatt 64 Stück).

Schon bei den beiden nächsten begriffen, dem Byte und Nibble hört die Standardisierung auf. Unter einem Byte versteht man heute 8 Bit. Doch dem war nicht immer so. Als Byte versteht man die Anzahl der Bits die man braucht um ein Zeichen in dem Zeichensatz des Computers abzulegen. Jeder Wert steht für einen Charaktercode. Der erste Standard der sich einbürgerte, kam vom American Standards Association es war der American Standard Code for Information Interchange (ASCII). Er hatte den Zweck die vorher unterschiedlichen Zeichensätze bei verschiedenen Computern zu vereinheitlichen. Wie der Name sagte, war es ein Zeichensatz für die USA. (eigentlich nach dem Wortlaut Amerika, doch spanisch sprechende Länder die Accents brauchen ignorierte der Standard). Er enthielt in den ersten 32 Positionen keine druckbaren Zeichen sondern Steuerzeichen, die bei einem Drucker oder Fernschreiber Aktionen auslösten oder in bestimmten Programmiersprachen zweckentfremdet als Stringende (Nullzeichen) genutzt wurden. Bis heute wichtig sind Tabulator (9), Zeilenvorschub (Carriage Return – cr) (13) und Wagenrücklauf (line feed lf) (10). In Windows wird jede Zeile von Wagenrücklauf und Linefeed abgeschlossen. Das Zeilenendzeichen in Unix ist es nur der Zeilenvorschub. Das hat historische Gründe, Windows übernahm das von DOS und dieses die Codierung von CP/M die sie für die damals noch üblichen Typenraddrucker einführte. Bei Unix hat man sich wohl gedacht das ein Zeichen genügt. Das ist bis heute so, so werden beim Kopieren von Winscp meine Pascal Quelltexte auf dem Raspberry Pi kleiner – das Programm ersetzt cr/lf durch Lf.

Seit etwa der siebziger Jahre sind daher 8 Bit die Standardgröße für ein Byte. Für ASCII braucht man eigentlich nur 7 Bit, doch da Computerarchitekturen meist ein Vielfaches von geraden Bitanzahlen verarbeiten, hat man das Byte auf 8 Bit gesetzt. Bei ASCII-Codes sind die Codes von 128 bis 255 daher nicht definierte und man nutzte sie für Erweiterungen. So z. B. die Umlaute die man in den USA nicht kennt oder Blockgrafikzeichen. Diese waren dann von Computer zu Computer unterschiedlich. So gab es in den Achtziger Jahren eigene Drucker für den Apple, C64, den IBM PC oder für andere populäre Computer die sich nur im Zeichensatz unterschieden.

Die 8 Bit breite Byte gilt in etwa seit Anfang der siebziger Jahre als die US-Regierung aktiv die Anschaffung von Computern förderte die den ASCII-Zeichensatz unterstützten. Den vorher war es so das jeder Hersteller seine eigene Codierung hatte und die meisten waren auch nicht 8 Bits lang sondern nur 6, Das reicht nur für 64 Zeichen. 26 Groß- und Kleinbuchstaben und 10 Ziffern ergeben zwar 62 Codierungen, doch man braucht ja noch einige andere Zeichen wie Satzzeichen, Klammern, Leertaste, mathematische Operationen und Steuerzeichen. So hatten diese 6 Bit Codierungen keine Kleinbuchstaben. Das sieht man in zahlreichen frühen Programmiersprachen wo Befehle nur in Großbuchstaben stehen wie Fortran oder Cobol.

IBM nutzte z.b. EBCDIC, ein Zeichensatz den es in sechs verschiedenen Versionen von 6 bis 8 Bits Breite gibt. Andere Hersteller hatten andere Codierungen so CDC in den ersten Modellen von Cray. Die Dominanz von 6 Bits in der frühen Computertechnik zeigt sich auch in Architekturen die ein Vielfaches von 6 Bits waren wie 12 Bit, 18 Bit und 30 Bit Rechner bei PDP (PDP-7, PDP-9 und PDP-10). Es gab auch 24, 48,36 und 60 Bit Rechner. Die Einführung der Oktalschreibweise in C, die man heute kaum noch braucht, drückt sich auch darin aus dass 3 Bit mit den Ziffern von 0 bis 7 ausgedrückt werden können. Das leitet über zum Nibble. Ein Nibble ist per Definition ein halbes Byte. Damit ist es auch nicht konstant groß, sondern war früher 3 Bits breit (Oktalnotation) heute dagegen 4 Bit breite Da man die 16 Zustände der 4 Bits nun nicht mehr mit den Zahlen von 0 bis 9 ausdrücken kann schreibt man heute Nibbles in Hexadezimalschreibweise auf der Basis von 16, wobei man die Buchstaben A bis F für sei werte von 10 bis 15 nimmt.

Also Bytes und Nibbles sind nicht standardisiert. Daher hat man als Standard auch einen anderen Begriff für das 8 Bit Byte gewählt: Oktett. Wer Standards z.B. für Internet Protokolle durchliest, wird diesen Begriff öfters lesen. Die Franzosen wird es auch freuen, denn die haben schon in den Achtzigern per Deklaration das Byte im Sprachgebrauch durch das Oktett ersetzt. Man hat ja dort eine Abneigung gegen Fremdwörter und will die Sprache französisch „rein“ halten.

Das einzige was nach dem Bit und Oktett standardisiert ist das Wort, bzw. Vielfache davon Doppelwort, Quadwort. Ein Wort entspricht der Bitanzahl der Architektur des Computers. Wenn man von der heutigen x86-Architektur, die den Speicher byteweise anspricht, den Blick auf andere CPU-Architekturen schweifen lässt, dann herrschte früher die wortweise Adressierung vor. Das war nur logisch: Der Datenbus war wortweise organisiert und so lud man immer ein Wort ein. Als Nebeneffekt hatte man so bei mehr als 8 Bits in der Architekt auch mehr Speicher. Die Cray 1 hatte in der Standardausführung z.B. einen Speicher von 1 MWorten was bei ihrer 64 Bit Architektur 8 Megabyte entspricht. RISC Prozessoren hatten, als sie einzogen, auch nur eine wortweise Adressierung bzw. Befehle zum wortweisen Verarbeiten von Daten. (ob dem heute noch bei den neuesten Exemplaren so ist weiß ich leider nicht).

Die nur wortweise Adressierung hat einige Vorteile. Der erste ist, dass man eine Menge Opcodes spart um Bytes oder andere Bruchteile eines Wortes als Operanden zu unterstützen. Das Verarbeiten von kürzeren Operanden macht nur in wenigen Fällen Sinn. Man muss z.b. drauf achten das die höherwertigen Bits von Registern nicht verändert werden, d.h. man kann nicht einfach die 8-bit-Operation durch eine wortweise Operation ersetzen. Sinn macht es nur bei Zeichenoperationen die früher eben immer 8 Bit umfassten (heute dank weiterer Standards auch 16 Bit). Früher waren Computer fast ausschließlich zum Rechnen da und Zeichenoperationen beschränkten sich meist auf die Ein/Ausgabe von Zeichenketten. So gab es in Crays Rechnern keine Operationen für 6 oder 8 Bits. Man packte eben einfach 10 bzw. 8 Zeichen in Wort und gab sie aus. Was man nicht brauchte, füllte man mit Nullbytes auf. Lediglich der Vergleich, den man mit dem Durchsuchen von Zeichenketten braucht, geht so nicht. Bei einigen 16-Bit Prozessorarchitekturen machte die byteweise Operationen einen Sinn wenn sie nur einen 8-Bit Datenbus hatten oder ihre ALU nur 8 Bit breit war, dann wurden die 16 Bit Operationen in zwei Durchgängen erledigt.

Die heutige Dominanz des Bytes und das man Worte oft als EDV-Begriff nicht (mehr) kennt, kommt daher das heute die x86 Architektur vorherrscht und die basiert auf der 8 Bit Architektur des 8080. Der 8086 hatte daher auch alle 8 Bit Verarbeitungsbefehle und adressierte wie der 8080 byteweise. Das war nicht bei allen damals neu erschienen Prozessoren. Der TMS 9900 adressierte z.B. nur 16 Bit weise (ganz durchdacht hatte man das Konzept aber nicht, denn der Adressbus war nur 15 Bit breit, sodass er in der Praxis auch nur 64 KByte ansprechen konnte). Andere Prozessoren wie der MC68000 hatten einen universelleren Ansatz und unterstützen byte, word und long word (so heißen in Motorola Nomenklatur 8, 16 und 32 Bit).

Ein zweiter Grund war die mit den ersten Personalcomputern entstandenen Anwendungen. Eine der ersten war Textverarbeitung. Sie erleichterte zuerst das Leben von Sekretärinnen und rationalisierte sie dann später weg. Texte zu verarbeiten bedeutet Zeichenketten zu verarbeiten und deren kleinste Einheit ist eben 8 Bit breit.
Was nicht standardisiert ist auch die Bezeichnung von Typen in Programmiersprachen. Im ursprünglichen C Standard steht z.B. nur die Reihenfolge der Typen, d.h. das ein int größer als ein short int ist. Der erste von Kerningham und Ritche für eine Fremdplattform (Honeywell 6000) übersetzte C-Compiler nutzte z.B. dort einen 6 Bit Code (die PDP-11 auf der C entwickelt wurde war eine 16 Bit Maschine mit 8 Bit Bytes), da dieser Rechner eine 36 Bit Architektur hatte. Alle Datentypen waren dort anders groß als auf der PDP-11. Wer schon in DOS Zeiten C programmierte wird auch noch wissen, das damals der Int auch nur 16 Bit breit war. Es wäre interessant zu wissen ob heute auf einem 64 Bit Compiler dann int 64 bits breit ist, bei 32 Bit Windows war er zumindest nur 32 Bit breit und 64 Bit waren dort ein long int. Ähnliches gibt es bei anderen Programmiersprachen. In Pascal ist der Typ Real auch nicht standardisiert. Turbo Pascal nutzte dafür 48 Bits, doch wenn man heute ein Programm mit Real als Datentyp schreibt wird man bald feststellen das es intern ein 64 Bit Wert ist – die 48 Bit Typen wurden durch Software berechnet und heute hat jeder Prozessor die Möglichkeit Fließkommazahlen in Hardware zu berechnen.

In jedem Falle sind die Bezeichnungen aus Programmiersprachen nicht standardisiert. Standardisiert sind die Bezeichnungen für Fließkommazahlen sowie ihr Aufbau und Genauigkeit in IEEE 754, doch deren Bezeichnungen wie „Binary64“ für den Typ Double (64 Bit Fließkommazahl) sind nicht allgemein üblich und Ganzzahlen hat IEEE leider nie standardisiert.

Wie bezeichnet man 16 Bits denn nun am besten? Also ich würde zu „16 Bit Wort“ greifen, schon alleine weil auch das Wort unterschiedlich groß sein kann (ich kenne Worte von 12 bis 64 Bit Größe).

14 thoughts on “Am Anfang war das Wort

  1. Der ASCII-Code mit seinen 7 Bit entstand dadurch, daß bei den damals üblichen 8-Kanal-Lochstreifen ein Prüfbit enthalten war. Damit waren nur noch 7 Informations-Bit übrig.

  2. Windows 32 Bit und 64 Bit unterscheiden sich kaum:

    short int : 16 Bit
    int : 32 Bit
    long : 32 Bit
    long long : 64 Bit
    size_t (Der Typ für alle Größen-/Längenangaben in der Standardlib) ist hingegen
    32 oder 64 Bit, je nachdem ob das Programm in 32 oder 64 Bit kompiliert ist.

    Mac OS X:

    short int: 16 Bit
    int : 32 Bit
    long: 32/64 Bit
    long long: 64 Bit
    size_t: 32/64 Bit

    War sehr nervig, als ich an altem Cross-Plattform Code arbeiten musste, in dem int und long wild gemischt waren. Sobald am Mac die 64-Bit Variante dazukam, passten plötzlich die Funktionen nicht mehr zueinander.
    Dieses unsägliche überflüssige long stammt meines Wissens noch aus der Windows 3.1 Zeit, als int 16 Bit und long 32 Bit waren.

  3. die Frage wie man 16 Bits in der Informationstechnik bezeichnet. Schon mal der Ansatz wie Hans diese Frage löst ist interessant. Ich würde in Google Books nachschauen oder in meinem Bücherregal. Hans stellt die Frage in einem Forum,

    Moment, ich hab auch in Büchern geguckt, sowohl aus meiner eigenen Bibliothek, als auch in welchen aus der Unibibliothek. Nur Google Books hab ich nicht verwendet. Ich wollte aber auch wissen, wie es andere Leute sehen, die keine Bücher schreiben, aber in der Praxis mehr damit zu tun haben als ich.
    Und was das Forum angeht, ich nehme an, Du meinst den Blog von Florian Freistetter, auf den ich unter dem anderen Artikel verlinkt habe. Die Leute die mir da geantwortet haben, sind in etwa so alt wie ich, und auch mit den 8 oder 16 Bit Rechnern der 80er Jahre aufgewachsen. Das weis ich von verschiedenen Diskussionen dort. Im übrigen kam die Beschäftigung mit der Frage nach der Wortbreite bei mir auch erst durch die Diskussion mit Andreas Buschmann auf. Und wie ich in den Kommentaren zum 8/16/24-Prozessor zuletzt (d.h. am 13. Juli 2015 um 01:38 Uhr) geschrieben habe, tendiere ich inzwischen auch dazu, von 16-Bit-Worten zu reden.

    Das einzige was nach dem Bit und Oktett standardisiert ist das Wort, bzw. Vielfache davon Doppelwort, Quadwort.

    Das ist so aber auch nicht richtig, denn auch auf x86-Rechnern ist ein Wort unter Windows zwar 16 Bit breit, unter Linux aber auch 32 bzw. 64 Bit breit, je nach verwendeter CPU.

    RISC Prozessoren hatten, als sie einzogen, auch nur eine wortweise Adressierung bzw. Befehle zum wortweisen Verarbeiten von Daten. (ob dem heute noch bei den neuesten Exemplaren so ist weiß ich leider nicht).

    Die CPU der AVR-Controller von Atmel basiert ja auch auf einer RISC-Architektur. Da ist der Programmspeicher in 16-Bit-Worten organisiert und wird auch so adressiert. Die Datentregister sind allerdings nur 8 Bit breit, wenn man die AVR32-MCUs aussen vor lässt.
    ARM-CPUs weisen einen 32 Bit breiten Befehlssatz auf, wie Wikipedia erklärt und haben auch sonst noch einige Eigenheiten, was den Zugriff auf den Datenspeicher angeht, die ich mir aber nicht genau angesehen habe. Wer es genauer wissen will, sollte sich auf der Webseite von ARM-Ltd. umsehen.
    Genauers weis ich dazu gerade auch nicht.

    Im ursprünglichen C Standard steht z.B. nur die Reihenfolge der Typen, d.h. das ein int größer als ein short int ist.

    Wenn das so da drin steht, sind die neueren Standards in gewisser Weise ja ein Rückschritt, denn die definieren es nicht mehr so genau. Stattdessen überlassen sie es den Compilerherstellern, und legen nur fest, dass es so sein soll:
    char <= int <= long <= long long
    Das kann im schlimmsten Fall dazu führen, dass alle 4 Typen gleich gross sind, (8 Bit nämlich) oder wie unter Turbo C/Cpp, dass sizeof(int) = sizeof(long) = 2 Byte bzw. 16 Bit.

  4. Dieses unsägliche überflüssige long stammt meines Wissens noch aus der Windows 3.1 Zeit

    Nö, dass kommt schon im C-Standard von 1989 vor. Guck mal in K’n R.

  5. „Dieses unsägliche überflüssige long stammt meines Wissens noch aus der Windows 3.1 Zeit, als int 16 Bit und long 32 Bit waren.“

    Ich vermute das geht eher auf die unsägliche Intel x86 Architektur zurück. Beim 68k gabs nie die Verwirrung, da das eben von Anfang an ein echter 32-bitter war.

  6. long gab es in C schon auf der PDP11, und da war:
    char: 8 Bit
    short int: 16 Bit
    int: 16 Bit
    long: 32 Bit
    char *: 16 Bit
    Das übliche Adressmodell war 64k Byte Code 64k Byte Daten, wobei die Daten nicht im Codespace liegen konnten. (Es gab auch das ursprüngliche Modell mit 64k Byte für alles.)

    Es gab wirklich CPUs, bei denen alle diese Datentypen 32 Bit groß waren, die konnten nichts anderes. Code bei dem signed und unsigned gemischt wurde war sehr häßlich zu portieren, da es keinen signed Typ gab der alle Werte von unsigned short aufnehmen konnte.

    size_t mit 64 Bit gibt es auch auf 32 Bit Rechnern mit 32 Bit long. Wird benötigt um Dateien größer 2 bzw. 4 GByte bearbeiten zu können. Heißt dann ggf. ssize_t .

  7. Da habe ich mich falsch ausgedrückt: Natürlich ist mir klar, dass es long schon ewig gibt. Was ich meinte, ist die übermäßige Verwendung von long, die ich selbst in aktuellem Windows/OSX Code noch finde. Seit Windows 95 gibt es keinen vernünftigen Grund mehr, long statt int zu verwenden, und schon gar nicht, das zu mischen. Das gilt natürlich nicht unbedingt für andere Plattformen.

  8. Also es ist wie ich schon schrieb: Der Standard definiert keine Größe der Typen und er lässt auch Sprachmonster wie long long zu. Das hat mit den betriebssystemen nichts zu tun sondern ist eine der Macken von C. An und für sich ist die Idee ja gut, nach der Sprachidee sollen sich die Typen ja an der CPU Architektur orientieren. Das Dumme ist eben bloß wie Andreas schon schrieb es gibt Architekturen nur mit Wordzugriff. Da machen die anderen Typen außer Int keinen Sinn und alle Typen implementiert keine CPU ohne Doppelbelegungen. Hier nochmal zum Nachlesen aus dem cpp standard, doch ich denke das ist 1:1 von C übernommen:
    http://de.cppreference.com/w/cpp/language/types

  9. Ich hab mal nach dem C89-Standard gesucht und bin leider nur noch bei Archive.org fündig geworden:

    Da lesen wir in Abschnitt 3.1.2.5 Types, 3. Absatz:

    There are four signed integer types, designated as signed char, short int, int, and long int. (The signed integer and other types may be designated in several additional ways, as described in 3.5.2)

    An object declared as type signed char occupies the same amount of storage as a „plain“ char object. A „plain“ int object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header ). In the list of signed integer types above, the range of values of each type is a subrange of the values of the next type in the list.

    Wenn man das genau nimmt, dann hätte der Typ int auf dem PC bzw. der Intel-Plattform eigentlich schon seit dem 386er 32 Bit umfassen müssen. (Aber das hätte natürlich diverse Komplikationen gegeben, wie sich die meissten hier sicher denken können, die noch mit DOS oder CP/M gearbeitet haben. – Ich kann mir aber auch ganz gut vorstellen, dass es gerade im wissenschaftlichen Umfeld Software (Betriebssyteme) gab, die das so umgesetzt hat.)

    Andrerseits liesst man vorher im Abschnitt 2.2.4.2 , Numerical limits, beispielhafte Vorgaben, die genau die Verhältnisse angeben, wie man sie etwa bei den alten Turbo Cpp Compilern für DOS vorfand:
    char: 8 Bit
    short int = int: 16 Bit
    long int: 32 Bit

    @Arne: Vermutlich hängt es davon ab, was die Entwickler genau wollen, wenn sie int und long mischen, bzw. mal dies mal jenes verwenden. Ich würde mir auf einem 64 Bit-System wahrscheinlich auch überlegen, ob ich eine Variable nur 32 Bit breit wähle, wenn klar ist, dass ich selbst diesen Wertebereich in dem speziellen Anwendungsfall nie ausnutzen werde.

  10. @Hans
    Die Architektur bezieht sich auf die Kombination von Soft- und Hardwarearchitektur. Der 386 ist zwar ein 32 Bitter, betrieben wurde er aber im 86-Realmodus mit 16 Bit. Auch Windows 3.1 nutzte das nicht aus, sondern den Protected Mode des 286, bei dem gab es mehr Speicher, aber immer noch 16 Bit breite Register.

    Eigentlich müsste bei einem 64 Bit Windows dann int 64 bit breit sein. Gerechterweise muss man sagen dass wegen der Komptabilität zum 32 Bit Windows auch andere Programmiersprachen die Größen gleich groß lassen. Compiliert man 64 Bit Delphi Programme so sind die Integer auch nur 32 Bit breit. Ich nehme daher bei neuen Programmen immer den neuen Typ nativeint der ist so breit wie die Architektur des Compilats.
    http://docwiki.embarcadero.com/RADStudio/XE8/de/Konvertieren_von_32-Bit-Delphi-Anwendungen_in_64-Bit-Windows

  11. @Bernd: Ich weis natürlich, dass die Kompatibilität der Software immer ein Problem ist, sobald die Register der CPU breiter werden. Ich bin ja selbst einer von denen, die nie der neusten Hardware hinterher laufen, sondern auch alte Hardware solange nutzen, wie sie funktioniert. Ich tausche Hardware auch meisst erst dann aus, wenn sie völlig veraltet oder kaputt ist, bzw. aktuelle Software darauf wirklich nicht mehr läuft, warum auch immer. Von daher finde ich es schon richtig, dass Software auch so gestaltet wird, dass sie nicht nur auf brandneuer Hardware läuft.

    Was ich im letzten Kommentar aber meinte ist, wenn man den Standard genau nimmt, dann hätte man auch in den 80er Jahren schon Software entwickeln können, die auch die Möglichkeiten des 386ers voll nutzt, wozu neben einem entsprechenden Betriebssystem dann auch passende Anwendungen gehören. Und ich nehme an (belegen kann ich es nicht) dass das zumindest im Bereich der universitären und/oder industriellen Forschung auch gemacht wurde. Oder man hat zumindest einige Anwendungssoftware so gestaltet, dass sie die Möglichkeiten der CPU voll ausnutzen konnte, selbst wenn das Betriebssystem das nicht konnte. Das DPMI *), also das DOS Protetcted Mode Interface würde ich in diese Kategorie einordnen, wobei das aber auch schon wieder ein Ergebnis solcher Experimente sein könnte, weil es ja erst heraus kam, als die 386er-CPU schon ein paar Jahre auf dem Markt war.

    —–
    Das DPMI war ein Treiber, der u.a. von Borland bei Turbo C/Cpp 3.x mitgeliefert wurde, um die CPU auch im Protected Mode betreiben zu können, damit man u.a. mehr Speicher ansprechen konnte, als unter DOS allgemein üblich.

  12. @Hans: Also zumindest der GCC hat bei i386-Code immer schon die Länge von „int“ auf 32 Bit gesetzt gehabt. M.W. haben auch die Intel-Compiler nicht anders agiert. Etwas merkwüdig ist eher, dass auf 64-Bit-CPUs der „int“ weiterhin bei 32 Bit geblieben ist und nur „long“ auf 64 Bit erweitert wurde. Das dient aber wohl dazu, die vier auf 64-Bit-CPUs möglichen Integer-Typen (also 8, 16, 32 und 64 Bit-Integer) mit den vier Standard-C-Typen char, short, int und long auswählen zu können.

  13. @Kai:
    Der gcc ist mit 32Bit int groß geworden. (VAX, mc68k, später RISC)
    Unterstützung für 16Bit int kam erst später dazu (Cygnus cross compiler).
    Unterstützung für 80386 kam erst später dazu, dafür mußte ein zusätzliches Modul für die Registerallozierung designed, geschrieben und eingebunden werden; der klassische Registerallozierer brauchte 8-12 32Bit Register.

    @Hans:
    Wer in den 80ern und in den frühen 90ern ein neues 32Bit System designed hat, hatte viele CPUs zur Auswahl: mc68k, VAX, IBM370/390, NS320xx, MIPS, Sparc, PA-RISC, ARM, Transputer, Intel RISC, …
    Der einzige Grund den 80386 zu nehmen war die Aufwärtskompatibilität zu 80286 und 8086.

    Diese Aufwärtskompatibilität war aber nicht nur im PC Bereich interessant, sondern auch im Embedded Umfeld. Die SEL/Alcatel ISDN Ortsvermittlungen haben z.B. Upgrades auf 80386 bzw. 80486 bekommen.

  14. @Kai Petzke:
    Wie Andreas Buschmann schon geschrieben hat, war es auch meine Ansicht (obwohl ich es nicht sicher wusste), das der gcc ursprünglich nicht aus der DOS-PC Welt stammt. Insofern wundert es mich nicht, dass der für int gleich 32 Bit nimmt. Als Student hab ich es auch noch mit einer PDP-11 zu tun bekommen, bei der int ebenfalls 32 Bit umfasste. Nur bei DOS-PCs war das anders. C-Compiler für Heimcomputer hat es zwar gegeben, aber das war, bevor C standardisiert wurde, bzw. während der Erarbeitung des Standards. Also können die nicht als Massstab genommen werden.

    Etwas merkwüdig ist eher, dass auf 64-Bit-CPUs der „int“ weiterhin bei 32 Bit geblieben ist und nur „long“ auf 64 Bit erweitert wurde.

    Sofern es sich dabei um x86-CPUs handelt, würde ich mal darauf tippen, dass das was mit der Windowswelt zu tun hat. Ansonsten vermute ich eher, dass das Compilerabhängig ist.

    Das dient aber wohl dazu, die vier auf 64-Bit-CPUs möglichen Integer-Typen (also 8, 16, 32 und 64 Bit-Integer) mit den vier Standard-C-Typen char, short, int und long auswählen zu können.

    Das könnte natürlich auch sein, halte ich aber Spekulation. Dann müsste man nämlich long long aus dem C99-Standard 128 Bits gross machen, während es auf anderen Compilern oder CPUs 64 Bits umfasst.

    Wer in den 80ern und in den frühen 90ern ein neues 32Bit System designed hat, hatte viele CPUs zur Auswahl: mc68k, VAX, IBM370/390, NS320xx, MIPS, Sparc, PA-RISC, ARM, Transputer, Intel RISC, …

    Und die Frage ist, wo sind sie alle geblieben? – Die Standardantwort wird wohl „Marktkonsultation“ heissen, denn mc68k, VAX und Transputer gibt es nicht mehr. Sparc noch vereinzelt, wenn ich recht informiert bin, aber was Oracle mit dem Teil der Hardwaresparte von Sun gemacht hat, die für die Sparc-Prozessoren zuständig war, weis ich nicht. Ob es IBM370/390 noch gibt, weis ich nicht, vermute es aber, und ARM gibt es ebenfalls noch. MIPS gibt es laut englischer Wikipedia auch nicht mehr als eingeständige Firma, also ist wohl die Frage berechtigt, wie lange das CPU-design noch bestand haben wird? – Blieben noch NS320xx, PA-RISC, und Intel RISC aus der Liste übrig. Von den 2 Ersten hab ich noch nicht gehört, (oder weis es gerade nicht) und Intel-Risc wird wohl als Technologie in deren aktuellen CPUs drin sein, aber sonst? – Keine Ahnung.

    Der einzige Grund den 80386 zu nehmen war die Aufwärtskompatibilität zu 80286 und 8086.

    Hm… also den Begriff Aufwärtskompatibilität finde ich jetzt etwas seltsam. Ich meine, in so einem Bereich wie CPUs sollte die Weiterentwicklung eines Designs auch immer all das können, was der Vorgänger auch schon konnte, nur besser. Das wäre allerdings Abwärtskompatibilität; – was also hab ich mir unter Aufwärtskompatibilität vorzustellen?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.