Padding
|
Der C-Standard (1999) sagt aus, daß in allen Integer-Typen mit Ausnahme der char-Typen Padding-Bits vorkommen können, also neuartige Bits neben den Wert-Bits und dem Sign-Bit in den vorzeichenbehafteten Integern. Im Zusammenhang können Trap-Repräsentationen der Bits entstehen. (Trap: Signal, Exception, Interrupt) Der Standard definiert nicht Anzahl, Positionen und Bedeutungen dieser Padding-Bits. Ebenso ist nicht definiert, daß diese Bits in allen Typen gleich sein sollen, falls sie existieren. |
Hardware
|
Ich habe mich seit geraumer Zeit dafür interessiert, mal ein Bit-Layout
mit darin enthaltenen Padding-Bits zu sehen. Zwei der gefundenen Dokumente (s.u.) habe ich näher betrachtet:
in irgendwelchen Daten-Integern. Ausnahmslos sind solche Komponenten in Pointern gespeichert. Pointer sind aber ohnehin schon (immer) speziell, besonders wenn man z.B. NULL und FAR-Pointer berücksichtigt. |
Konse-
|
|
Gedanken
|
Prozessoren transportieren Daten stets in Maschinenwortbreite. Pointer haben auf einer Plattform nur eine Speicherbreite: Maschinenwortbreite. Integer-Typen gibt es jedoch in mehreren Breiten:
Sind diese oben enthalten oder werden sie hinzugefügt?! Problematisch ist sicherlich: 4 Padding + 1 Sign + 3 Wert-Bits = 8 Bits! Ebenfalls problematisch: 4 Padding + 60 Wert-Bits = 64 Bits Desweiteren problematisch: 64 Wert-Bits + 4 Padding + 60 Füllbits = 128 Bits! Weiterhin problematisch: In einem Maschinenwort können z.B. 8 Bytes gespeichert werden. Jedes mit eigenem Padding-Feld? Oder ein Padding-Feld für das Maschinenwort? Dann passen nur noch 7 Wert-Bytes hinein. Aber wenn die Bytes keine eigenen Padding-Bits mehr haben, dann ... In einem Pointer jedoch können vollkommen unproblematisch z.B. 48 Adressen-Bits und 6 Padding-Bits und 10 Füll-Bits gespeichert werden. Eine Akzeptanz für Wertbereiche, die nicht auf einer Anzahl Wert-Bits 2N (-1) beruhen, wird es wohl nicht geben. Von der Bedeutung eines Padding-Bits her ist nur ein Paritäts-Bit oder eine breitere Prüfsumme prinzipiell sinnvoll, in einem integer Objekt gespeichert zu sein. Praktisch jedoch nicht: Ein Paritäts-Bit war bereits in Gemeinschaft mit einem 7Bit-Wert reichlich unsicher, und breitere Prüfsummen reduzieren den Wertbereich stark. Ein ReadOnly-Bit wäre unsinnig. Es müßte ja jedesmal ein Objekt gelesen werden, um diesen Bit-Wert zu erfahren. Einen Pointer hingegen braucht man für jeden Zugriff ohnehin. Auch Zugriffssperren sind über Adressen sinnvoll realisiert/realisierbar. Schon vor langer Zeit hatten manche Prozessoren getrennte Daten- und Adressen-Register. Auch dies deutet darauf hin, daß Pointer strukturiert werden können/sollten. Innerhalb von Daten-Integern jedoch haben meiner Meinung nach nur Wert-Bits oder Sign+Wert-Bits eine sinnvolle Daseinsberechtigung. Padding-Bits darin wären vollkommener technischer Unsinn!
Ich glaube nicht, daß ein solcher Prozessor jemals am Markt erscheinen wird. Praxisgerecht ist es wohl nicht, hier pauschal strikt konform zu programmieren. Es sei denn, man 'verliert' gar nichts dadurch oder es ist unbedingt gefordert. Dies ist eine pragmatische Sichtweise: Welche Vorteile brächte es in der Praxis? Welche Nachteile brächte es in der Praxis? Allgemein erwartet man von einem neuen Prozessor nur Vorteile und keine Nachteile! Natürlich kann ein Prozessor mit Padding-Bits innerhalb der Daten-Integer geschaffen werden. Dieser könnte/würde sogar irgendwelche Vorteile aufgrund dieser Padding-Bits besitzen. Ich kann nicht behaupten, daß hier niemals Vorteile resultieren können! Aber, ohne (triftige) Nachteile kann solches nicht einhergehen! Es ist beispielsweise der Sicherheitsaspekt zu beachten: Allein eine vielfältige exotische Abweichung eines solchen Prozessors gegenüber den bisherigen Prozessoren erhöhte die Wahrscheinlichkeit für beliebige Fehler. Der C-Standard hat durch seine Definition der möglichen Padding-Bits bereits die Fehlerwahrscheinlichkeit stark erhöht! - Ja, das ist so! Es ist etwas Neues aufgetaucht, das mannigfaltig beachtet werden muß/soll und das konkrete zusätzliche Aktionen verursacht und vieles schwieriger macht. Der C-Standard hat den Programmierern in ihre Integer gespuckt! . |
Mehr
|
Padding-Bits sind übersetzt Füll-Bits. Dennoch meint der Standard hier eher Bits wie Parity-Bits und weitere Bits, die von ihrer Bedeutung her Trap-Repräsentationen ergeben können. Der Wert von Füll-Bits ist nämlich irrelevant und wird mit X gekennzeichnet. Füll-Bits sind auch schon länger weit verbreitet und haben bisher nicht gestört. Beispielsweise werden 80 Bit breite Gleitkommawerte auf 32Bit-Plattformen mittels 3×32 = 96 Bit übertragen, es werden also 16 Füll-Bits angehängt. Und Füll-Bytes gibt es schon immer innerhalb von Strukturen zwecks Alignment. Es wird oft gefragt, was denn der Sinn der Padding-Bits sein könnte. Geantwortet werden meist falsche Erklärungen:
In der Praxis jedoch werden bei Übertragungen anspruchsvolle Prüfverfahren auf ganze Datenblöcke angewandt, oder der Arbeitsspeicher wird per ECC geschützt, und zwar vollkommen transparent, etc. Es ist nicht ersichtlich, was Prüfsummen innerhalb eines jeden einzelnen Dateninteger-Objektes so sinnvoll macht. Infineon TriCore 32Bit — C99-Compiler Tasking/AltiumAlle Typen, von _Bool über long long bis long double, sind vorhanden.Alle Integer: 0 .. 2N-1 bzw. -2N-1 .. 2N-1-1, 2er-Komplement. N: 8, 16, 32, 64. Also Nn = 2 Nn-1. Nur Wert-Bits und Sign-Bit vorhanden. Typen der Spezial-Formate: (signed / unsigned) __frac __sfrac __laccum __packb __packuw Es findet also eine Abgrenzung statt, mittels plattform-spezifischer Schlüsselwörter. Aus dem C-Standard:
Es ist ein ganz mieses Konzept, wenn
ein Typen-Modell heraus, das Mist ist. Aufgrund von Definitionen des C-Standards läuft es immer auf ein doppelt so breites Objekt hinaus, sobald Padding-Bits für ein bestehendes Objekt überlegt werden! Zur Zeit erscheint nur die Möglichkeit, Padding-Bits in einem 128bit-Format von vornherein vorzusehen, weil hier der Zahlenbereich immens ist. |
Links |