Warum meckern eigentlich viele über den x86?

Oi!Olli

Grand Admiral Special
Mitglied seit
24.12.2006
Beiträge
16.479
Renomée
862
  • BOINC Pentathlon 2011
  • BOINC Pentathlon 2017
  • BOINC Pentathlon 2019
  • THOR Challenge 2020
  • BOINC Pentathlon 2021
Ist mir schon öfters aufgefallen. Die Architektur bremst und alte Zöpfe müssen ab etc.

Jetzt frage ich mich aber wieso? Der Erfolg der Architektur ist nun einmal auch ihrer Abwärtskompatibilität geschuldet es ist nicht nur sehr praktisch das man seine alte Software noch einsetzen kann auch neue Software läuft meistens noch unter älteren Rechnergenerationen.

Was wäre denn wenn man wirklich einen neuen Chip entweickeln würde der sagen wir mal 40 % schneller ist? Zu Anfangs würde es gar nichts bringen weil die Software nicht vorhanden wäre und später dürfte man bei einem Umtausch sämtliche Software neu kaufen und da habe ich mal großzügig ausgelassen das man vielleicht noch auf andere Programme ausweichen darf weil es die Lieblings- oder Standardsoftware für das neue System nicht gibt.

Dann wäre noch das Problem das man mit Pech auch alle Rechner austauschen dürfte weil die Daten der neuen Software nicht mit denen der alten Software kompatibel ist (keine Ahnung wie das bei Software ist die auf dem Server liegt).

Und zu guter letzt was ist mit den Chips passiert die es mit der Kompatibilität nicht so genau genommen haben wie der Pentium Pro (langsam unter 16 Bit und dem Itanium (langsam unter 32 Bit) oder dem Itanium? Beide haben keine wirkliche Massenhafte Verbreitung erfahren.

So das war mein Senf dazu., Kritik, Gegenargumente oder Lob nehme ich ab jetzt entgegen.
 
Und zu guter letzt was ist mit den Chips passiert die es mit der Kompatibilität nicht so genau genommen haben wie der Pentium Pro (langsam unter 16 Bit und dem Itanium (langsam unter 32 Bit) oder dem Itanium? Beide haben keine wirkliche Massenhafte Verbreitung erfahren.
Dir ist schon klar, daß in deinem C2Quad im Prinzip der PPro als Urahn steckt?

Cherry
 
der PPro hat den P2 und P3 beerbt, das vielleicht noch was vom PPro im C2D oder C2Q steckt, was noch annähernd so ist wie damals wage ich zu bezweifeln. und selbst wenn, who cares wenn zum beispiel die besagte 16bit performance nicht so der knaller ist. wieviele 16bit programme laufen denn heute noch? hast du ein 64bit OS, vielleicht sogar vista64? da ist eh nix mehr mit 16 bit.
 
der PPro hat den P2 und P3 beerbt
Andersrum. Erst Pentium (1, P5-Kern), dann PPro (P6-Kern), dann PII/PIII (P6-Weiterentwicklungen), dann P4(NetBurst), dann Core (Entwicklung auf P6-Basis)

who cares wenn zum beispiel die besagte 16bit performance nicht so der knaller ist. wieviele 16bit programme laufen denn heute noch? hast du ein 64bit OS, vielleicht sogar vista64? da ist eh nix mehr mit 16 bit.
Genau das ist der Punkt. Das der PPro selber nicht so erfolgreich war, liegt einerseits an der 16-Bit-Schwäche, und andererseits an der Cache-Integration. Beides wurde mit dem PII deutlich verbessert, und mittlerweile würde eine 16-Bit-Schwäche (so sie vorhanden wäre) sowieso keinen mehr interessieren.

Das "Problem" bei X86 ist halt, daß der CPU-Befehlssatz im Laufe der Zeit gewaltig gewachsen und dabei nicht gerade übersichtlicher geworden ist. Assembler für ATmel-AVR zu schreiben macht richtig Spaß, für X86 ist das sehr viel schmerzhafter (ich mußte zum Glück nur 2-3 Praktika damit machen im Studium). Das andere Problem ist, daß die CPUs intern auch schon lange kein X86 mehr verstehen, sondern das alles aufwendig in den CPU-Befehlssatz übersetzt werden muß. Das sind alles Dinge, die X86 als Ballast mitschleppt. Ein schlankes, neues, durchdachtes CPU-/Befehlssatz-Design könnte da sicher mit weniger Aufwand (Transistorpower) ähnliche Leistungen wie aktuelle X86-CPUs erreichen. Aber aber... gegen die in Massen vorhandende Basis an X86-Software sieht man halt kein Land.

Und daß X86 allen (theoretischen) Hemmschuhen zum Trotz schnell sein kann, sieht man ja jeden Tag. Es kostet halt die Entwickler mehr Schmerzen.


Cherry
 
Andersrum. Erst Pentium (1, P5-Kern), dann PPro (P6-Kern), dann PII/PIII (P6-Weiterentwicklungen),

ja nichts anderes sag ich ja, hab ich es mal wieder bei "beerbt" verdreht? (ich vererbe und meine kinder sind die beerbten)
 
ja nichts anderes sag ich ja, hab ich es mal wieder bei "beerbt" verdreht? (ich vererbe und meine kinder sind die beerbten)
Genau :-) Derjenige, der es kriegt, hat jemanden anders beerbt.

Chery
 
also wars ja doch richtig
 
Das alte Technologie immer mitgezogen wird ist doch vollkommen verständlich?
Wo wird denn in der Industrie mal irgendwo ein Schnitt gemacht und 100% komplett neu entwickelt? Jede neue Auto-Generation hat seine Wurzeln in irgendeinen Vorgänger.


Wenn ich schon die paar Software Probleme mit Linux sehe (Will ich nicht, da läuft kein MSWord...) sehe ich riesengroße Beton-Wände bei der Einführung einer komplett neuen Hardware incl.(!!) komplett neuer Software.
Du kommst da auf ein Henne/Ei Problem, wer macht den ersten Schritt?

Ohne Software keine Käufer dieser neuen Hardware.
Ohne Käufer keine Software für diese neue Hardware.
Für beide ist es ein enormes Risiko in solch einen Markt einzusteigen solange der x86 Markt so stark ist.

Mit der 64 Bit Umstellung passiert doch eh schon ein langfristiger und weitreichender Wandel.
AFAIK sind 16 und 32 Bit Befehle auf einer 64 Bit CPU nurnoch "emuliert" (oder wie immer man das auf Prozessor-Ebene nennen mag).
 
AFAIK sind 16 und 32 Bit Befehle auf einer 64 Bit CPU nurnoch "emuliert" (oder wie immer man das auf Prozessor-Ebene nennen mag).
16bit gibt es nicht mehr, die Opcodes sind neu belegt. 32bit funktioniert nahezu so wie vorher auch. Emuliert wird zwar bei 16bit, aber nicht durch die CPU. Das macht dann eine Software wie dosemu.
.
EDIT :
.

Ein schlankes, neues, durchdachtes CPU-/Befehlssatz-Design könnte da sicher mit weniger Aufwand (Transistorpower) ähnliche Leistungen wie aktuelle X86-CPUs erreichen.

Jein. Schau dir mal an, welchen Cache-Aufwand aktuelle RISC-CPUs betreiben müssen, um ihre Leistung zu entfalten.
 
16bit gibt es nicht mehr, die Opcodes sind neu belegt. 32bit funktioniert nahezu so wie vorher auch. Emuliert wird zwar bei 16bit, aber nicht durch die CPU. Das macht dann eine Software wie dosemu.

Du hast natürlich Recht, 16 Bit wird schon längere Zeit per Software emuliert (WinME konnte es doch noch in Hardware, oder?)

Ich habe jetzt auch IA-64 im Kopf, wo die 32 Bit Befehle eher lieblos noch angehangen wurden um eine Abwärtskompatibilität zu halten.
Aktuelle Desktop Prozessoren laufen AFAIK mit Intel64 (bzw. AMD64) Erweiterungen.
 
Du hast natürlich Recht, 16 Bit wird schon längere Zeit per Software emuliert (WinME konnte es doch noch in Hardware, oder?)

Ich habe jetzt auch IA-64 im Kopf, wo die 32 Bit Befehle eher lieblos noch angehangen wurden um eine Abwärtskompatibilität zu halten.
Aktuelle Desktop Prozessoren laufen AFAIK mit Intel64 (bzw. AMD64) Erweiterungen.

Also erstmal müssen wir zwischen IA32 (inklusive x86_64) und IA64 unterscheiden. IA64 ist generell separat zu betrachten. Wie dort der x86 Teil jetzt umgesetzt ist, weiß ich gar nicht. Dächte aber, dass der jetzt per Software-Emulation erledigt wird, seit man auf die Alpha-Technik Zugriff hat.

Was IA32 angeht, dort gibt es verschiedene Modi. Seit x86_64 ist aber (unter 64bit) der 16bit Real Mode weggefallen. Da existiert dann nur noch der 32bit Protected Mode, in den die CPU umschalten kann. Das heißt, 64bit und 32bit Code werden nativ auf der CPU ausgeführt (nix Emulation), während 16bit Code auf einen Emulator (Software) angewiesen ist.
 
16bit gibt es nicht mehr, die Opcodes sind neu belegt. 32bit funktioniert nahezu so wie vorher auch. Emuliert wird zwar bei 16bit, aber nicht durch die CPU. Das macht dann eine Software wie dosemu.

Sicher?

Meine alten Bootdisketten dürften dann ja nicht mehr laufen was sie aber noch tun.
 
Also erstmal müssen wir zwischen IA32 (inklusive x86_64) und IA64 unterscheiden. IA64 ist generell separat zu betrachten. Wie dort der x86 Teil jetzt umgesetzt ist, weiß ich gar nicht. Dächte aber, dass der jetzt per Software-Emulation erledigt wird, seit man auf die Alpha-Technik Zugriff hat.


Ich hab nur gelesen, dass IA64 voll 64 Bit ist mit noch einem kleinem veralteten 32 Bit Anhang, wärend IA32 mit AMD64 oder intel64 scheinbar tatsächlich "richtige" 32 Bit Prozessoren mit 64 Bit Erweiterung sind.

Mehr kann ich momenan nicht finden.

http://de.wikipedia.org/wiki/IA-64

Die IA-64 unterstützt hardwaremäßig auch die IA-32 auf dem Stand des Pentium III.
 
Das alte Technologie immer mitgezogen wird ist doch vollkommen verständlich?
Wo wird denn in der Industrie mal irgendwo ein Schnitt gemacht und 100% komplett neu entwickelt? ...
Speziell die Halbleiterwelt ist voll davon, auch Intel hatte mehrere Versuche unternommen andersartige CPUs auf den Markt zu bringen.

http://de.wikipedia.org/wiki/Intel_iAPX_432
http://de.wikipedia.org/wiki/Intel_i860

Auch Motorolas Entscheidung, zugunsten der Power Architektur (RISC), die eigenen CISCs (68000) in den Hintergrund zu stellen, war ein scharfer Schnitt.

MFG Bobo(2009)
 
Sicher?

Meine alten Bootdisketten dürften dann ja nicht mehr laufen was sie aber noch tun.
Ich meine, so bald die CPU im Long Mode (64 bit) ist, sind 16bit vorbei. Da die CPUs vom BIOS aber nach wie vor im 16bit Real Mode initialisiert werden, funktionieren 16bit Anwendungen grundsätzlich noch.
Ich hab das etwas sehr blöd geschrieben. Es gibt natürlich noch sämtliche Adressierungsarten, auch bei den aktuellsten x86_64 CPUs. Starten tun die im PC immer noch im 16bit Real Mode. Danach werden sie vom OS entweder in den 32bit Protected Mode (32bit OS) oder 64bit Long Mode (64bit OS) geschaltet. Und im Long Mode gibts keine 16bit Befehle mehr, weil die Opcodes dort von den neuen 64bit Befehlen belegt sind. Will man da 16bit Software laufen lassen, braucht man einen Emulator, der eine 16bit CPU mit emuliert.
 
Speziell die Halbleiterwelt ist voll davon, auch Intel hatte mehrere Versuche unternommen andersartige CPUs auf den Markt zu bringen.

http://de.wikipedia.org/wiki/Intel_iAPX_432
http://de.wikipedia.org/wiki/Intel_i860

Auch Motorolas Entscheidung, zugunsten der Power Architektur (RISC), die eigenen CISCs (68000) in den Hintergrund zu stellen, war ein scharfer Schnitt.

MFG Bobo(2009)

Das es Versuche und Schritte gegeben hat ist schon klar, aber der Mainstream ist es i.d.R. nicht gewesen.
Es gibt auch Beispiele in der Automobilundustrie wo man ganz neue Ansätze gemacht hat.
AFAIK hat die Mercedes A-Klasse auch kein Vorgänger-Chassis.
Seine Anfänglichen Probleme sind jedoch hinreichend bekannt ;D (oder auch der Audi-TT *noahnung*)

Was ich eigentlich sagen wollte:
Es ist absolut keine Schande "alte" und jahrelang geprüfte und erprobte Technik auch heute noch in "moderne" Geräte zu verbauen.
Eine Neuentwicklung muss ja auch erstmal beweisen, dass sie "besser" als der Vorgänger ist.
 
Das es Versuche und Schritte gegeben hat ist schon klar, aber der Mainstream ist es i.d.R. nicht gewesen. ...
Kompatibilität: Du stellst etwas als Normalfall hin, was eine Zeit lang völlig unüblich war im Computerbereich.

Erst IBMs 360-Rechnerserie hat eine ISA (OS/360 und später zOS) genutzt, die unabhängig von der jeweiligen Microarchitektur lief. Bis dahin hat man in der IT ständig das Rad neu erfunden (neue Chips, neues Betriebssystem, neue Anwendungen), wenn Rechner entworfen wurden.

Im Grunde genommen befinden wir uns in der Post-RISC-Zeit. Derzeit wird bei den Entwicklern überlegt in wie weit ein Prozessor wie der TRIPS mit "reinen" EDGE-Instruktionen gefüttert wird (-> Neu), oder ob es mit vorhandenen Instruktionssätzen ebenso verwirklicht werden kann.
Bei einem potenziellen Larrabee-Nachfolger (wenn nicht schon der Larrabee selber) ist der Preis der Kompatibilität eine hohe Komplexität (-> Wärmeentwicklung/Strombedarf, verdeckte Bugs).
Bei von Grund auf neuen Chips entfällt ein Teil der Komplexität. CPUs wie der Tilera64 sind deswegen extrem genügsam.

Was die Stärke von x86 ausmacht ist, neben der Kompatibilität, die Qualität der Fertigung. So konnte in der Vergangenheit manch eine Schwäche der damaligen x86-Prozessoren durch höheren Takt ausglichen werden.

MFG Bobo(2009)
 
Zuletzt bearbeitet:
Kompatibilität: Du stellst etwas als Normalfall hin, was eine Zeit lang völlig unüblich war im Computerbereich.


Damals gab es aber kein Mainstream, keine Standards und kaum private Nutzung von solchen Rechnern/Hardware.
Damals war es also durchaus Möglich die paar (i.d.R. doch hauseigenen) Programme auf eine neue Plattform zu portieren.

Wobei Andersherum...
ich weiß von diversen Versicherungen die noch immer auf Großrechnern mit feinster Cobol Programmierung setzen und dessen Programme seit teilweise 30-40 Jahre unangetastet sind *buck*
 
... Wobei Andersherum...
ich weiß von diversen Versicherungen die noch immer auf Großrechnern mit feinster Cobol Programmierung setzen und dessen Programme seit teilweise 30-40 Jahre unangetastet sind *buck*
Dann könnte es sich um IBM Rechner der z-Familie handeln ... IBM behandelt die z-Rechner als Nachfolger der 360-Familie.

medium.jpg
Quelle

MFG Bobo(2009)
 
Zuletzt bearbeitet:
da gibt es noch 2 weitere Probleme:

- Der Code ist mittlerweile unlesbar *suspect*
- Die Programmiersprache wird kaum noch gelehrt. Als Greenhorn würde ich da nicht eine einzige Zeile anpacken!

Als richtig guter Cobol Programmierer kannst Du Dir eine goldene Nase in solchen Firmen verdienen.


Es sollte ja auch nur als ein Gegenbeispiel zu Bobo_Oberon guten Einwänden herhalten ;)

Dort sitzt der Kern in 40 Jahre alter Hard- und Software und wurde dennoch die letzten 40 Jahre den Ansprüchen entsprechend erweitert.



In unserer Firma machen wir nun auch einen heftigen Schnitt und portieren langfristig all unsere Programme weg von der Siemens S7/SMP16 komplett auf Beckhoff.
Dafür ist unser GUI-Terminalprogramm auch schon gute 20 jahre alt und wurde noch unter DOS Programmiert *hmpf*
 
Zuletzt bearbeitet:
und hier wäre ein zeitpunkt für die prozessorhersteller weitere zöpfe abzuschneiden.
 
x86 hat designtechnisch deutliche schwächen, iese werden aber kaschiert durch gute fertigung hohen takt und gigantischen entwicklungsaufwand.
Alleine die Befehle ordentlich zu dekodieren, um Pipeline-stalls zu vermeiden ist eine herausforderung. Übrigens eines der Geheimnisse der guten IPC der core2s und nehalems.
x86 ist komplex, zig verschiedene betriebs- und adressierungsmodi, verschieden lange befehle, wenige register usw.
Da sind andere architekturen wesentlich "angenehmer" in der Hinsicht, nur sind die eben nicht kompatibel. Und wer kauft schon einn prozessor auf dem keine Software läuft.
Apple ist einer der wenigen Hersteller die radikale brüchemit der architektur ein paar male mit einigem erfolg durchgezogen haben...
fakt ist, X86 ist nicht unbedingt der weisheit letzter schluss in Sachen design und effizienz eines rechensytems, aber es ist nunmal da, die dominante architektur und wird uns daher noch einige jahre begleiten.
Übrigens ein schönes beispiel dafür, dass sich nicht zwangsläufig die technisch bessere technologie am markt durchsetzt... (erinnert mich irgendwie an die videokassetten...!? )

grüßchen
ich
 
Zurück
Oben Unten