Macs sind nur noch gewöhnliche PCs

[abgemeldeter Benutzer]

Das fängt schon damit an, das es keine x86er sind, sondern einfach x86-Code "verstehen". Intern wird doch komplett anders gearbeitet.

Das war schon immer so. Das ist ein Gundprinzip von CISC bzw. des x86.

 

[-Nuke-]

Das war schon immer so. Das ist ein Gundprinzip von CISC bzw. des x86.

Nope. Es wird so gemacht, wie gesagt, aber es ist kein "Grundprinzip".

edit:
Verwechsle das nicht mit der "Arbeitsweise" von CISC. Bei CISC sendest du einen Befehl, aus dem dann mehrere Befehle entstehen (Memory-Befehl, ALU-Befehl, etc.). Bei "heutigen" x86ern von Intel und AMD werden diese "Unterbefehle" noch mals gesplittet.

 

[Gremlin]

Ich frage mich, wie ich die langen Jahre zurecht gekommen bin mit meinen Macs. Ich wusste gerade mal, dass eine CPU in dem Ding werkelte und nur beim PPC-Transit wurde ich mal darauf aufmerksam. Vom Rest der Hardware hatte ich noch weniger Ahnung.

Auf dass, was Apple mir über die Macs erzählte, habe ich kaum je gehört. Es ist eine Firma die ihre Produkte verkaufen will, und ich mag weder Werbung noch Marktgeschrei.

Solange hier ein Mac steht, der genau das tut, was ich möchte, ist meine Apple-Welt in Ordnung.

Genau. Ob da jetzt ein Prozessor von IBM, Freescale, Intel oder AMD drinsteckt, ist doch sowas von egal - Hauptsache das Ding läuft.

Das ist es, was für mich den Mac ausmacht: ein Rechner, der ohne grosse Probleme, Wartungsaufwand oder sonstigen Ärger einfach seinen Job macht und mich meinen machen lässt, ohne mir in die Quere zu kommen. Von daher betrachte ich diese ganze Diskussion mit leichtem Unverständnis...

Gremlin

 

[abgemeldeter Benutzer]

Nope. Es wird so gemacht, wie gesagt, aber es ist kein "Grundprinzip".

edit:
Verwechsle das nicht mit der "Arbeitsweise" von CISC. Bei CISC sendest du einen Befehl, aus dem dann mehrere Befehle entstehen (Memory-Befehl, ALU-Befehl, etc.). Bei "heutigen" x86ern von Intel und AMD werden diese "Unterbefehle" noch mals gesplittet.

Na gut, es ist kein Grundprinzip von CISC, sondern des x86:
Wir entwerfen einen Befehlssatz ohne Sinn und Verstand, den kein Prozessorkern verarbeiten kann, dann entwerfen wir einen Prozessorkern mit einem anderen Befehlssatz und damit das ganze zusammengeht eine Einheit, die die Befehle umwandelt. Da das nicht richtig läuft, entwerfen wir einen neuen Prozessorkern mit einem anderen Befehlssatz und wiederum einen neue Einheit, die die Befehle umsetzt. Und das immer wieder von neuem, anstatt mal den Befehlssatz, der das eigentliche Problem darstellt, zu ändern.

Und weil jeder weiss, dass der Befehlssatz weder Sinn, noch Verstand hat, wird der neue Prozessorkern mit dem neuen Befehlssatz an die große Glocke gehängt, um Glauben zu machen, dass jetzt alles besser wäre.
Tatsächlich hat sich aber nichts geändert.
(Oder um ein beleibtes Zitat der Intel-Switch-Befürworter aufzugreifen: Es ist doch egal, was drin steckt.)


Im Gegensatz dazu ist beim PowerPC von vorne herein ein Befehlssatz mit Sinn und Verstand entworfen worden, den der Prozessorkern gut verarbeiten kann. Um hier Verbesserungen zu erreichen müssen nicht dauernd neue Kerne mit neuen Befehlssätzen und neue Einheiten, die die Befehle umsetzen entwickelt werden, hier muss nur hier und da am Kern gefeilt werden.


Es ist schon paradox, dass Apple einen Schnitt macht, obwohl es gar nicht nötig ist, zu einer Plattform, die einen Schnitt bitter nötig hätte, wo der aber nie gemacht wurde oder werden wird.

 

[Gremlin]

Na gut, es ist kein Grundprinzip von CISC, sondern des x86:
Wir entwerfen einen Befehlssatz ohne Sinn und Verstand, den kein Prozessorkern verarbeiten kann, dann entwerfen wir einen Prozessorkern mit einem anderen Befehlssatz und damit das ganze zusammengeht eine Einheit, die die Befehle umwandelt. Da das nicht richtig läuft, entwerfen wir einen neuen Prozessorkern mit einem anderen Befehlssatz und wiederum einen neue Einheit, die die Befehle umsetzt. Und das immer wieder von neuem, anstatt mal den Befehlssatz, der das eigentliche Problem darstellt, zu ändern.

Und weil jeder weiss, dass der Befehlssatz weder Sinn, noch Verstand hat, wird der neue Prozessorkern mit dem neuen Befehlssatz an die große Glocke gehängt, um Glauben zu machen, dass jetzt alles besser wäre.
Tatsächlich hat sich aber nichts geändert.
(Oder um ein beleibtes Zitat der Intel-Switch-Befürworter aufzugreifen: Es ist doch egal, was drin steckt.)


Im Gegensatz dazu ist beim PowerPC von vorne herein ein Befehlssatz mit Sinn und Verstand entworfen worden, den der Prozessorkern gut verarbeiten kann. Um hier Verbesserungen zu erreichen müssen nicht dauernd neue Kerne mit neuen Befehlssätzen und neue Einheiten, die die Befehle umsetzen entwickelt werden, hier muss nur hier und da am Kern gefeilt werden.


Es ist schon paradox, dass Apple einen Schnitt macht, obwohl es gar nicht nötig ist, zu einer Plattform, die einen Schnitt bitter nötig hätte, wo der aber nie gemacht wurde oder werden wird.

Das die x86er-Architektur einige Altlasten mit sich rumträgt, bestreitet im Grunde ja keiner. PowerPC ist vom Prinzip her sicherlich eleganter und einfacher - deswegen konnten die PPC-Prozessoren über viele Jahre trotz eines Bruchteils an Entwicklungsbudget in der Performance mit der x86er-Architektur mithalten oder waren sogar besser. Das ändert aber nichts daran, dass die Entwicklung eines konkurrenzfähigen Prozessors unglaublich teuer ist und immer teurer wird - und das gilt auch für den PPC. Für die paar Prozent Marktanteil die Apple hat ist das einfach nicht mehr rentabel. Deswegen konzentriert sich Freescale auf Embedded-Systeme und IBM auf fette Serverprozessoren und Spielekonsolen. An Desktop-Prozessoren sind beide aufgrund der erdrückenden Übermacht von Intel und AMD nicht wirklich interessiert - da ist einfach kein Geld mit zu verdienen.
Mittlerweile sind die Prozessoren so komplex, dass das Frontend, das die x86er-Prozessoren brauchen, um den x86er-Befehlssatz in internen Microcode umzuwandeln, keine grosse Rolle mehr spielt.

Gremlin

 

[Incoming1983]

Und das immer wieder von neuem, anstatt mal den Befehlssatz, der das eigentliche Problem darstellt, zu ändern.

Das macht durchaus Sinn, weil dann die Software nicht geändert werden muß.

Ein modernes OS läuft auf einem 13 Jahre alten Rechner, und ein 13 Jahre altes OS läuft auf einem modernen Rechner - wenn man möchte.

Das ist z.B. etwas, das bei apple nicht geht.

 

[Coda]

EFI ist ein Firmware-Interface. Und die Firmware beim x86 heißt BIOS.

Nur mal um das Missverständnis von vornherein auszuschließen: Glaubst du das ein x86-Prozessor ohne BIOS nicht lauffähig ist?

Das ist nämlich nicht der Fall. Es gibt z.B. LinuxBIOS (der Name tut nichts zur Sache, sondern bezieht sich nur darauf was es ersetzt). Das ganze bootet direkt einen Linux-Kernel vom Firmware-Chip (nix mehr mit legacy 16-bit-Code, es wird direkt in den Protected-Mode gewechselt in den ersten paar Instructions - das Licht deiner Zimmerlampe braucht länger um in deine Augen zu gelangen als das Ding braucht um in den Protected-Mode zu schalten wenn du den Powerknopf drückst).

Es würde mich auch stark wundern wenn das x86-EFI auf das alte BIOS aufbaut. Es gibt keinen Grund dafür. Es wird vermutlich viel eher ein Emulationslayer verwendet um alte BIOS-Interrupts auch noch verarbeiten zu können.

# BIOS emulieren (also Kompatibilität zu vorhandenen BIOS)

Und wiedermal ein Mythos weniger.

Na gut, es ist kein Grundprinzip von CISC, sondern des x86:
Wir entwerfen einen Befehlssatz ohne Sinn und Verstand, den kein Prozessorkern verarbeiten kann

Damals wurde x86 sehr wohl direkt verarbietet.

dann entwerfen wir einen Prozessorkern mit einem anderen Befehlssatz und damit das ganze zusammengeht eine Einheit, die die Befehle umwandelt. Da das nicht richtig läuft, entwerfen wir einen neuen Prozessorkern mit einem anderen Befehlssatz und wiederum einen neue Einheit, die die Befehle umsetzt. Und das immer wieder von neuem, anstatt mal den Befehlssatz, der das eigentliche Problem darstellt, zu ändern.

G5 hat mehr Decoding-Stages als ein Conroe, d.h. er verbraucht mehr Zeit damit die Befehle zu "verstehen" und auf seine Einheiten zu verteilen - soviel erstmal dazu.

Klar braucht man etwas mehr Logik um die x86-Befehle in Micro-Ops zu zerlegen, andererseits geht das aber heutzutage genauso schnell (der Athlon 64 benützt z.B. einen Massive-Parallel-Predecoder der jeden Takt 4 x86-Instructions dekodieren kann, obwohl die Instruction-Länge nicht vorher bekannt ist) wie bei einem RISC-Befehlssatz und andererseits sind die variablen Befehlslängen von x86 eine Art Huffman-Coding. Alles was oft gebraucht wird ist kurz. Die Programme sind ggü. PowerPC kleiner was sich vorteilhaft auswirkt weil den Instruction-Cache damit besser auslasten kann. Zudem kann das Decoding-Frontend mit einem gleich großen Instruction-Window mehr Parallelität aus x86 ziehen als aus PowerPC, da mehr Metainformationen in den Instructions gespeichert sind (z.B. Load/Store und Addition zusammen).

Es sind beides Von-Neumann-Architekturen, die sich nach dem Frontend vom Prozessor-Design kaum noch unterscheiden.

So archaisch wie du tust ist x86 seit dem 386 eh nicht mehr. Du solltest dir evtl. mal die Instruction-References von beidem zu Gemüte führen bevor du wild in die Gegend hinein interpretierst.

Und weil jeder weiss, dass der Befehlssatz weder Sinn, noch Verstand hat, wird der neue Prozessorkern mit dem neuen Befehlssatz an die große Glocke gehängt, um Glauben zu machen, dass jetzt alles besser wäre.

Nirgends hat Intel jemals direkte Spezifikationen zu den intern verwendeten µOps veröffentlicht oder damit "geprahlt". Es wurde veröffentlicht wie viele Recheneinheiten vorhanden sind o.Ä., aber das tut IBM ja auch.

Im Gegensatz dazu ist beim PowerPC von vorne herein ein Befehlssatz mit Sinn und Verstand entworfen worden, den der Prozessorkern gut verarbeiten kann.

Den man heute aber auch schon wieder dekodieren muss um entsprechende Out-Of-Order-Execution überhaupt zu ermöglichen. Das interne Befehlsformat ist kein PowerPC bei G5. Ganz und gar nicht.

Um hier Verbesserungen zu erreichen müssen nicht dauernd neue Kerne mit neuen Befehlssätzen und neue Einheiten, die die Befehle umsetzen entwickelt werden, hier muss nur hier und da am Kern gefeilt werden.

Das gilt auch für RISC (joo das kann ich belegen, gibt genügend Ars-Technica-Artikel zu G5 und G4 )

 

[mattmiksys]

Das macht durchaus Sinn, weil dann die Software nicht geändert werden muß.

Ein modernes OS läuft auf einem 13 Jahre alten Rechner, und ein 13 Jahre altes OS läuft auf einem modernen Rechner - wenn man möchte.

Das ist z.B. etwas, das bei apple nicht geht.

Soweit die Theorie, wenn das "moderne OS" dann nicht Windows ist, oder umgekehrt...

 

[lundehundt]

Glaubst du wirklich, dass es der tiefere Sinn hinter dem x86 Befehlssatz ist auf einem modernen x86 Rechner WIN 95 laufen zu lassen.

 

[minilux]

Glaubst du wirklich, dass es der tiefere Sinn hinter dem x86 Befehlssatz ist auf einem modernen x86 Rechner WIN 95 laufen zu lassen.

ETWA NICHT???? -- mach mein Weltbild nicht kaputt kopfkratz

 

[Incoming1983]

Glaubst du wirklich, dass es der tiefere Sinn hinter dem x86 Befehlssatz ist auf einem modernen x86 Rechner WIN 95 laufen zu lassen.

Das ist Teil des Konzeptes.

Beispiel: Kunde hat Software für zigtausend EUR gekauft, die läuft nur unter Win95. Ups, nach 10 jahren ist der Rechner putt. Also für 400 EUR neuen Rechner hingestellt, wieder Win95 installiert, und gut ist.

Oder umgekehrt: Aus alter Hardware läßt sich immernoch was zusammenbauen und produktiv nutzen.

Hab jetzt z.B. Gentoo Linux 2006.1 auf einem 486er SX 25Mhz mit 32 MB Ram installiert. Er kann als Webserver für statische Seiten dienen, als FTP Server oder als NAT Router, jeweils für DSL. Das Ding hab ich vor 6 Jahren für 24 DM ersteigert, und war danach noch ca. 3 Jahre bei mir in Produktion in og. Einsatzgebiet. Ach ja, Samba lief auch drauf, wenn auch langsam.

 

[minilux]

Das ist Teil des Konzeptes.

Beispiel: Kunde hat Software für zigtausend EUR gekauft, die läuft nur unter Win95. Ups, nach 10 jahren ist der Rechner putt. Also für 400 EUR neuen Rechner hingestellt, wieder Win95 installiert, und gut ist.

oT: das hört sich nach Arztpraxis an: da laufen auf neuesten P IVs auch noch Patientenverwaltungstools in DOS Boxen -- ein Konzept würde ich dahinter nicht vermuten

 

[Incoming1983]

oT: das hört sich nach Arztpraxis an: da laufen auf neuesten P IVs auch noch Patientenverwaltungstools in DOS Boxen -- ein Konzept würde ich dahinter nicht vermuten

Da vielleicht nicht ;-).

Trotzdem hat sich gezeigt, daß modulare x86er Hardware noch den höchsten "Recyclingwert" besitzt. Ein paar alte Teile kann ich heute noch zusammenbauen, und damit was halbwegs sinnvolles anfangen, bei fast allen "geschlossenen" Systemen ist das schwieriger (AtariST, Amiga, Archimedes, alte Apples etc. pp).

 

[Gremlin]

Glaubst du wirklich, dass es der tiefere Sinn hinter dem x86 Befehlssatz ist auf einem modernen x86 Rechner WIN 95 laufen zu lassen.

Es geht nicht immer um das Betriebssystem, sondern darum, existierende Software ohne eine Performance kostende Emulation auf einem neuen Rechner weiter benutzen zu können. Apple muss das jetzt schon das 2. Mal machen, was jedes mal Entwicklungsaufwand bedeutet und Kunden verärgert - siehe diese und diverse weitere Diskussionen. Hätte Apple 1984 auf den 8086 gesetzt, wäre das noch nie notwendig geworden. Das konnte man damals natürlich noch nicht wissen - und aus der Perspektive von 1984 war die Entscheidung für Motorola richtig, der 68000er war dem 8086 haushoch überlegen.

Gremlin

 

[Generalsekretär]

So archaisch wie du tust ist x86 seit dem 386 eh nicht mehr.

Ich fürchte, für ._ut ist Alles, was x86 kann, wertloses Teufelszeug.

Nirgends hat Intel jemals direkte Spezifikationen zu den intern verwendeten µOps veröffentlicht oder damit "geprahlt". Es wurde veröffentlicht wie viele Recheneinheiten vorhanden sind o.Ä., aber das tut IBM ja auch.

Ich glaube, er meinte den x86-Befehlssatz, der nach seiner Meinung absolut nichts taugt, und zu dem immer wieder neue CPU-Kerne mit dazu passenden Dekodierern gebaut werden müssen.

Falls ich seine Meinung richtig verstanden habe, frage ich mich, was genau er meint. Micro-RISC gibt es doch erst seit PentiumPro (?), auf dessen Architektur Alles bis einschließlich Pentium-III basiert.
Der P-IV war ein Neuentwurf (also Nummer 2 in dieser Sichtweise), dessen Andersartigkeit v.A. auf hohe Taktfrequenzen ausgerichtet war.
Der Pentium-M und Nachfolger ist dann die Nummer 3 dieser Reihe, die es seit 1995 oder 1996 gibt.
Man korrigiere mich bitte, falls ich hier falsch liege bzw. ._ut falsch interpretiere.

 

[minilux]

Trotzdem hat sich gezeigt, daß modulare x86er Hardware noch den höchsten "Recyclingwert" besitzt. Ein paar alte Teile kann ich heute noch zusammenbauen, und damit was halbwegs sinnvolles anfangen, bei fast allen "geschlossenen" Systemen ist das schwieriger (AtariST, Amiga, Archimedes, alte Apples etc. pp).

ja, aber in der Praxis läufts doch eh wieder anders:
wir hatten letztes Jahr Firmenweit die Umstellung von W2K auf XP, vorher wurden 6 Monate lang Listen geführt welches Tool sich unter XP anders verhält wie vorher, veraltete Hardware (afair alles unter PIII 800Mhz) wurde im Rahmen der Umstellung durch neue ersetzt und gut wars (btw: auch da fielen einige Tools hinten runter weil die unter W2K gut funktionierten, unter XP aber nicht zum Laufen zu kriegen waren)

 

[Thowe]

oT: das hört sich nach Arztpraxis an: da laufen auf neuesten P IVs auch noch Patientenverwaltungstools in DOS Boxen -- ein Konzept würde ich dahinter nicht vermuten

Das ändert sich, die KBV wirds schon richten.


Es gibt aber viele andere Gebiete, wo sowas in der Art auch nötig ist. Weswegen es z.B. von Tyan auch noch Mainboards für Pentium 4 gibt, die ISA Slots haben. So eine Karte mag mal in der Entwicklung einer Kleinserie locker je Stück an die 10.000,- Euro und mehr gekostet haben, wenn man dann keine Hardware mehr bekommt in der sie läuft, ist das alles nur durch erneuten Einsatz hoher Geldmittel zu kompensieren. Dazu addieren sich Probleme wie zertifizierte Systeme wie solche die eine med. Zulassung benötigen.

 

[minilux]

Das ändert sich, die KBV wirds schon richten.

die KBV richtet was?? Da kann man ja gespannt sein

 

[Thowe]

die KBV richtet was?? Da kann man ja gespannt sein

Eigentlich sollte es schon lange keine DOS basierende Software für Arztpraxen geben, die KBV hatte AFIR ab 2005 den Einsatz des DOS-Prüfmoduls untersagt. Bis auch AFIR Januar 2006 (zur Einführung der eGesundheitskarte) sind dann noch Koexistenz erlaubt, sprich, DOS Software und Abrechnung übers Windowsprüfmodul.

 

[s_herzog]

Falls ich seine Meinung richtig verstanden habe, frage ich mich, was genau er meint. Micro-RISC gibt es doch erst seit PentiumPro (?), auf dessen Architektur Alles bis einschließlich Pentium-III basiert.
Der P-IV war ein Neuentwurf (also Nummer 2 in dieser Sichtweise), dessen Andersartigkeit v.A. auf hohe Taktfrequenzen ausgerichtet war.
Der Pentium-M und Nachfolger ist dann die Nummer 3 dieser Reihe, die es seit 1995 oder 1996 gibt.
Man korrigiere mich bitte, falls ich hier falsch liege bzw. ._ut falsch interpretiere.

Der Pentium IV ist keine Neuentwurf. Er ist nur "gepimpt" und zwar schlecht ;-)

Der Pentium M ist auch nur "gepimpt", aber im Gegensatz dazu halt "gut"

Die ISA "Instruction Set Architecture" vom x86 wird halt dekodiert und als µops in der CPU verarbeitet. Das ist aber KEIN Merkmal von "CISC", denn der erhabene "Pentium" war noch ein echter CISC mit fest verdrahtetem Befehlssatz. CISC heißt nur "mächtige lange Befehle, mit denen viel gemacht werden kann". RISC heißt "kleine, einfache, unmächtige Befehle, die dafür aber höllenschnell sind".