Thema: Das war's - verabschieden wir uns vom 80386.

[Svenska]

Hallo,

Linux 3.8 wird keine Unterstützung mehr für den 80386 haben. Aktuelle Versionen von FreeBSD unterstützen den 80386 ebenfalls nicht (wenn man "386" auswählt, bekommt man "486"), gleiches gilt für NetBSD. Die GCC-Leute diskutieren gerade, den Support ebenfalls einzustellen. Die nächste bzw. übernächste Version von GCC dürfte den Support also nicht mehr bereitstellen.

Die letzte neu verfügbare CPU, die nicht 80486-kompatibel ist, dürfte vermutlich der Vortex86SX mit 300 MHz sein (nicht der Vortex86DX). Der 80386 unterstützt die Befehle XADD, BSWAP, COMPXCHG und INVLPG nicht, die mit dem 80486 eingeführt wurden und für atomische Operationen notwendig sind. Eine gleichzeitige Unterstützung von "80386" und "SMP-kompatibel" in einem Betriebssystem ist nicht möglich und fehlerhafter Code wird auf 80486+ fehlerfrei ausgeführt.

Damit stellt sich die Frage nicht mehr, ob man den 80386 in seinem Hobby-OS noch unterstützen sollte.

Gruß,
Svenska

[kevin]

Ich glaube, die meisten von uns haben auf 386-Support eh schon verzichtet. Ich benutze jedenfalls überall invlpg ohne groß zu prüfen, ob ich das überhaupt darf...

[XanClic]

Hm, die Befehle braucht man für atomare Operationen? Ich dachte, xchg ist automatisch ge-LOCK-t, oder war das beim 386 noch nicht so?

Und invlpg kann man auch durch Schreiben von CR3 in sich selbst bekommen. Auch wenn das nicht schön ist.


Mit xchg kann man sich also Mutexes bauen. Und mit Mutexes wiederum kann man faktisch alle Operationen atomar machen, auch wenn sie im Prinzip nicht atomar sind – oder nicht?

Gut, es wird alles nicht sehr schön, aber die Aussage, dass man für 386er keinen SMP-kompatiblen Code schreiben kann, wage ich doch anzuzweifeln… Es sei denn, xchg war auf dem 386 nicht atomar.

[Jidder]

Man will manchmal nicht nur, dass die Operationen atomar sind, sondern auch, dass sie lock-free oder wait-free sind, um bestimmte Performancegarantien zu bieten. Und viele Algorithmen dafür lassen sich nur (oder einfacher) mit cmpxchg, etc. umsetzen.

[kevin]

Das sind halt die optimierten Versionen. Meines Wissens taugt das xchg auf dem 386er schon für Locks, und das ist alles, was man braucht, damit SMP überhaupt funktionieren kann.

Praktisch gesehen dürfte das größere Problem allerdings sein, einen 386er mit mehreren CPUs aufzutreiben.

[Svenska]

Hallo,

man kann Code, der eine Emulation für atomare Instruktionen nutzt, nicht mit Code mischen, der dafür spezielle Instruktionen nutzt, weil beide Ansätze sich ausschließen. Das heißt, dass alle Bibliotheken und Anwendungen die Emulation benutzen müssen, um auf 80386 zu funktionieren, was für Linux-Distributionen irgendwie unpraktisch ist. Windows NT unterstützte übrigens Dual-386-Systeme.

Baut man für 80386, erzeugt der Compiler Code, der die fehlenden Instruktionen vermeidet. Baut man für 80486+, dann kann der Kernel die fehlenden Instruktionen zur Laufzeit emulieren, was aber nicht dazu kompatibel ist. Außerdem ist so eine Emulation auf dem 386er dann nicht SMP-tauglich.

Kurz: invlpg kann man im Kernel kompatibel durch ein mov cr3 ersetzen, compxchg nicht.

Gruß,
Svenska

[XanClic]

Hatten wir nicht schonmal eine Diskussion hier, ob man lock cmpxchg für Mutexes durch xchg ersetzen kann? Soweit ich mich erinnere, war der Stand damals, dass das geht. Und das ist dann keine Emulation, xchg ist atomar.

Mir ging es (wie kurz erwähnt) auch nicht darum, ob SMP auf 386 dadurch auch besonders schön möglich ist, sondern nur, dass es im Prinzip funktional genauso gut wird wie auf 486+ – natürlich gibt es da klitzekleine Leistungseinbußen, wenn man jedes invlpg durch ein mov eax,cr3; mov cr3,eax ersetzt und jede atomare Operation durch einen xchg-Mutex lockt, aber das ändert ja an der prinzipiellen Funktionalität nichts (wohingegen du meintest, „Eine gleichzeitige Unterstützung von ‚80386‘ und ‚SMP-kompatibel‘ in einem Betriebssystem ist nicht möglich“).

[Svenska]

Hallo,

wohingegen du meintest, „Eine gleichzeitige Unterstützung von ‚80386‘ und ‚SMP-kompatibel‘ in einem Betriebssystem ist nicht möglich“

War vielleicht etwas hart formuliert, schließlich gab es solche Systeme und sie haben offensichtlich auch funktioniert. Denke dir ein "sinnvolle" und ein "modern" an passenden Stellen in den Satz, dann passt das.

Der 80386-Support ist jedenfalls ein Maintenance-Alptraum, weil die Probleme nicht auffallen, bis man einen echten 386er auspackt, den fast niemand mehr hat. Selbst wenn, mit den max. 33/40 MHz (Intel/AMD) ist das einfach zu langsam. Mein kleinster 32-Bitter ist ein 486SX/25 und auch Qemu fängt erst bei einem mäßig akkuraten 486er an.

Für weitergehende Studien hier ein paar Links:
http://lkml.indiana.edu/hypermail/linux/kernel/1212.1/01152.html ist der Pull Request für den Kernel
http://gcc.gnu.org/ml/gcc/2012-12/msg00079.html ist ein Startpunkt in der Diskussion auf der GCC-Mailingliste

Gruß,
Svenska

[erik.vikinger]

Hallo,


selbst der erste 8086 war bereits voll SMP-fähig (wurde auch in realer Hardware umgesetzt), dafür gab es das Lock-Signal und im x86-Befehlssatz das Lock-Präfix das meines (verblassten) Wissens nach mit allen Befehlen die auf den Speicher zugreifen nutzbar ist. Der Vorteil von XCHG ist der das dieser Befehl das Lock-Präfix implizit immer dabei hat (spart eben ein Byte) und bei modernen CPUs manchmal auch das Cache-Kohärenz-Protokoll etwas abkürzen kann. Die neuen Befehle des 486er bieten einfach nur ein bisschen mehr Bequemlichkeit und Performance aber keinen echten funktionalen Fortschritt.


Grüße
Erik

[Roadrunner]

Wo wir schon davon sprechen: Wie ermittelt man eigentlich die minimalen/optimalen Systemanforderungen für ein bestimmtes Programm? Beim OSDev kann man sich ja noch am verwendeten Befehlssatz und den vorhandenen Treibern orientieren, aber wie sieht es aus, wenn man "normale" Programme vertreiben will?

[Jidder]

Tests würde ich mal sagen. Zuerst würde ich definieren, was "das Programm ist brauchbar" und "das Programm läuft optimal" heißt. Dann würde ich testen auf welchen Maschinen es diese Definition erfüllt und jeweils die schwächste Ausstattung als Mindest- bzw. Optimalanforderung deklarieren.