10. November 2012 14:44

Re: Endlich ...

moritz94 schrieb am 10. November 2012 12:58

> x86 an sich ist ja gar nicht schlecht,

AUA. x86 ist der Irrsinn in Tüten.

Rede mal mit den Leuten, die Compileroptimierung machen, die fluchen
nur.
Außer, sie haben das Tal der Tränen bereits hinter sich, dann finden
die das gut - das hält die Konkurrenz vom Leib.

Virtualisierung geht heute noch nicht richtig. Es gibt immer noch
einige (sehr wenige) Maschinenbefehle, die man in einer VM nicht zu
100% nachbilden kann. Und eine ganze Menge Maschinenbefehle, die man
nur sehr aufwändig nachbilden kann.
Das hat dann die Konsequenz, dass Virtualbox usw. für jedes
Betriebssystem spezielle Anpassungen braucht, weil jedes
Betriebssystem diese schwierigen Befehle anders nutzt und eben auf
die Schnauze fällt, wenn ein GPT-Diagnose-Befehl irgendwo ein
Statusbit anders setzt als das beim Test auf der realen Maschine war.
(Die IBM-360-Architektur hat auch ihre bösen Macken, aber die war
schon in den 80ern problemlos virtualisierbar. Nur mal so als
Hinweis, wie ALT manche Schwächen der Intel-Architektur schon sind.)

Intel bringt es auch fertig, gigantische Mengen an Betriebszustand im
Prozessor zu halten, der bei jedem Interrupt (eigentlich)
ausgetauscht werden müsste, aber gleichzeitig eine immer noch winzige
Anzahl Register für Programme zu machen. Und es gleichzeitig dem
Interrupt Handler schwer zu machen, diesen Zustand auch sauber zu
sichern.
ARM kriegt das besser hin. Sparc sowieso, für den Interrupt Handler
liegen die Register sowieso im RAM und er arbeitet sowieso mit einer
eigenen Adresse. Im Prinzip regelt das der Prozessor, wann Daten
zwischen CPU und RAM verschoben werden.

Die Spezialregister der x86-Architektur sind auch so ein Thema. Für
Blockbefehle grundsätzlich CX... was ich da alles an Umkopierorgien
zwischen Prozessorregistern schreiben musste, das ist echt nicht mehr
schön.
Heute sind die Register flexibler, aber die Codierung ist ineffizient
- die Befehle mit wenigen Bytes sind nun mal die, die CX als
Schleifenzähler vorsehen, die lassen sich auch nicht mehr ändern.
Damit ist x86-Maschinencode grundsätzlich umfangreicher als
Maschinencode für einen Prozessor mit einer vernünftigen Architektur
- was auf der Platte heutzutage ziemlich egal ist, im Prozessorcache
aber nicht.

> vor allem stabil und
> ausgereift

Du hast offenbar die Bug-Datenblätter von Intel nicht gesehen.
Die CPUs haben heutzutage mehr, nicht weniger Bugs als früher. Es
fällt nur nicht so furchtbar auf, weil sie auch insgesamt viel mehr
Features enthalten.

Ich frage mich manchmal wirklich, wie man einer CPU überhaupt noch
systemkritische Anwendungen anvertrauen kann. Oder warum manche
Softwareleute immer noch davon träumen, endlich fehlerfreien Code zu
schreiben - auf 0% lässt sich die Fehlerrate nicht drücken, die
CPU-Fehler verhindern das.

> - nur die paar Hacks bei der Initialisierung stören mich
> halt

Die sind fast noch das Harmloseste.
Wenn da was in die Hose geht, bootet die Maschine nicht, dann merkt
man wenigstens gleich, was los ist.
Mich erschrecken die unauffälligen Bugs viel mehr.
Cachekohärenzprobleme beispielsweise - merkt keine Sau, bis
irgendwann mal jemand wirklich 512 Prozessoren aufs gleiche RAM
loslässt. (Was aber keiner tut, weil dann die CPUs nur noch mit
Cachekohärenz beschäftigt sind. Ergo gibt es alle paar Millarden
Zugriffe falsche Daten - merkt doch keine Sau. Aber vielleicht hat's
die NSA gemerkt und nutzt den Fehler, um die Barrieren des
Betriebssystems zu umgehen... wenn der Fehler nicht sogar extra
eingeschmuggelt wurde.)

Ich fürchte sehr, dass heutige CPUs so komplex sind, dass sich da
absichtliche und irrtümliche Abweichungen von den Spezifikationen gar
nicht mehr vermeiden lassen.
Das gilt natürlich nicht nur für x86, aber die x86-Architektur ist
durch die vielen noch unterstützten Altarchitekturen derart komplex,
dass das Problem dort schlimmer sein müsste als anderswo.

Anzeige

heise online Themen