B
Badener
ste^2 schrieb:
Wäre ganz angebracht!
Die ewige PPC vs Intel Diskussion
- Ersteller 4motion
- Erstellt am
Wäre ganz angebracht!
D
Dr. NoPlan
Können wir jetzt in gepflegter Form bitte wieder auf das ursprüngliche Thema zurück kommen! 
CRen
Aktives Mitglied
- Dabei seit
- 31.12.2003
- Beiträge
- 2.718
- Reaktionspunkte
- 225
Diese ganze Diskussion ist doch hahnebüchen.
Fakt ist doch, dass OS X unter den Core Duo-Prozessoren gefühlt WESENTLICH flotter ist als noch auf den G3, G4 und G5-Rechnern, oder?
Die RAM-Geschichten sind mir recht egal, habe meinen iMac Core Duo auf 2 Gigs aufgerüstet und keinen Unterschied zu einem Gig gemerkt. Das MB meiner Freundin könnte hingegen 512 MB extra vertragen, das ist keine Frage.
Wenn ich vergleiche, wie lange mein Powerbook 1,25 brauchte, um eine DVD zu rippen und wenn ich das mit dem Core Duo vergleiche... Wow! Beim Powerbook waren maximal 10 Frames drin, der Core Duo macht 50 pro Sekunde. DAS ist Fortschritt, egal was all die Unken rufen.
Ach ja: Mein PC auf der Arbeit ist ein Pentium mit 3,2 Gigahertz, 2 Gigabyte RAM und Windows XP. Und jetzt ratet mal, was schneller läuft: Der iMac oder der Pentium, der ja *eigentlich* flotter sein müsste...?
Anfangs hatte ich auch bedenken, aber dieser Intel-Umstieg ging so schmerzlos und wurde so gut von den Software-Entwicklern unterstützt, dass man nur staunen kann. Schließlich darf man nicht vergessen, dass der Umstieg auf Intel gerade 6 Monate her ist. Und bis auf Word und Adobe und einige ältere Spiele hab' ich alles, was ich so nutze, als Unibin auf dem Rechner.
Also wo ist das Problem? Warum überhaupt Diskutieren? Ich bin sicher, dass die Unibin-Geschichte einen Zweck hat und Apple jederzeit ein Hintetörchen offen hält, um wieder PPC zu nutzen, wenn denn IBM mal den Ar*** hochkriegen sollte.
Wie ist das eigentlich: Gibt es auch reine Intel-Applikationen für OS X oder geht das ausschließlich über Universal Binaries?
Gruß,
Christian
Fakt ist doch, dass OS X unter den Core Duo-Prozessoren gefühlt WESENTLICH flotter ist als noch auf den G3, G4 und G5-Rechnern, oder?
Die RAM-Geschichten sind mir recht egal, habe meinen iMac Core Duo auf 2 Gigs aufgerüstet und keinen Unterschied zu einem Gig gemerkt. Das MB meiner Freundin könnte hingegen 512 MB extra vertragen, das ist keine Frage.
Wenn ich vergleiche, wie lange mein Powerbook 1,25 brauchte, um eine DVD zu rippen und wenn ich das mit dem Core Duo vergleiche... Wow! Beim Powerbook waren maximal 10 Frames drin, der Core Duo macht 50 pro Sekunde. DAS ist Fortschritt, egal was all die Unken rufen.
Ach ja: Mein PC auf der Arbeit ist ein Pentium mit 3,2 Gigahertz, 2 Gigabyte RAM und Windows XP. Und jetzt ratet mal, was schneller läuft: Der iMac oder der Pentium, der ja *eigentlich* flotter sein müsste...?
Anfangs hatte ich auch bedenken, aber dieser Intel-Umstieg ging so schmerzlos und wurde so gut von den Software-Entwicklern unterstützt, dass man nur staunen kann. Schließlich darf man nicht vergessen, dass der Umstieg auf Intel gerade 6 Monate her ist. Und bis auf Word und Adobe und einige ältere Spiele hab' ich alles, was ich so nutze, als Unibin auf dem Rechner.
Also wo ist das Problem? Warum überhaupt Diskutieren? Ich bin sicher, dass die Unibin-Geschichte einen Zweck hat und Apple jederzeit ein Hintetörchen offen hält, um wieder PPC zu nutzen, wenn denn IBM mal den Ar*** hochkriegen sollte.
Wie ist das eigentlich: Gibt es auch reine Intel-Applikationen für OS X oder geht das ausschließlich über Universal Binaries?
Gruß,
Christian
P
pret
Aehm immer wenn ich über solche Sachen wie Macbook verarbeitung klagen höre... denk ich mir haben solche Leute schon mal ein ibook in der Hand gehabt? das waren noch ganz andere Spaltmasse!
Der iMac.CRen schrieb:
Allerdings müßte dein Pentium nicht "eigentlich" flotter sein.
Es kommt nicht nur auf die Taktfrequenz an.
Beim Vergleich Pentium M/Core Duo und Pentium 4 ist die Diskrepanz zwischen Taktfrequenz und Leistung sogar verdammt groß.
Klar.CRen schrieb:
A
abgemeldeter Benutzer
Da hier hinter meinem Rücken weitergeschossen wird, möchte ich mich doch noch einmal zu Wort melden.
Hier wird ja von manchen Leuten behauptet, ich würde Falschaussagen machen und Märchen verbreiten. Leider halten sich diese Leute nicht für nötig, sich näher mit dem Thema zu beschäftigen, um meine Aussagen mit Fakten zu widerlegen. Sie investieren ihre Zeit lieber darin, mich zu diffamieren.
Da ich mit diesem Post wieder zur Zielscheibe von konzertierten Trollaktionen werden dürfte werde ich mich an der folgenden "Diskussion" nicht beteiligen und bin wieder weg.
Zum Thema.
64bit beim PPC
Die IBM-Dokumente ignoriere ich nicht. (Als ich mich weigerte einen Link zum 3D-Forum zu klicken, konnte ich ja nicht wissen, dass dort - nach Monaten Diskussion - endlich mal eine IBM-Dokumentation konsultiert wurde. Die hatte ich allerdings schon vor Jahren überflogen.) Die IBM-Dokumente werden von den 3D-Forums-Leuten so interpretiert, dass sie daraus lesen können: "._ut redet gerade Müll".
In den IBM-Dokumenten steht, dass es einen 32bit-Modus gibt.
Jetzt gibt es mehrere mögliche Interpretationen, wie Mac OS X die Modi behandelt.
Interpretation der 3D-Foren-Leute:
Der Kernel muss 64bit sein. Denn sonst kann der 64bit-Modus nicht eingeschaltet werden (diese Leute kennen nur x86/x64, da ist das so.)
Dem widersprechen aber verschiedene Dinge.
Zum einen sind die Treiber 32bit. In der Doku spricht IBM davon, dass das zwischen den Modi auf Per-Prozess-Basis gewechselt werden kann. Kernel und die Treiber sind bei Mac OS X aber ein einziger Prozess. Wenn also di Treiber 32bit sind, kann der Kernel nicht 64bit sein.
Das bestätigt sich auch, wenn man sich den Kernel anschaut, der ist keine ppc/ppc64-Universal-Binary (bzw. Fat-Binary), sondern eine flat-PPC-Binary. Auch die Apple-Dokumente sprechen davon, dass der Kernel nicht 64bit sein müsse. (Diese Dokumente werden von den 3D-Foren-Typen als Propaganda abgetan.)
Aus der Interpretation der 3D-Foren-Leute würde sich zwangsläufig ergeben, dass 32- und 64bit-Code innerhalb eines Prozesses gemischt werden kann. (Diese Leuten, die nur x86/x64 kennen, müssten hier eigentlich wieder schreien: Das ist nicht möglich.)
Möglich wäre das nur, wenn im 64bit-Modus auch 32bit-Code läuft (der 32bit-Modus also gar nicht verwendet wird). Das geht nicht, wenn die Modi umgeschaltet werden *müssen*.
Wie man sieht ist diese Interpretation voller Widersprüche. (Was aber nicht stört, denn sie bestätigt ja das wichtigste und umumstößliche Faktum: "._ut redet Müll"
Meine Interpretation der Sache sieht folgendermaßen aus:
Der 32bit-Modus wird von Mac OS X überhaupt nicht benutzt. Da sich beim PowerPC der Befehlssatz und das Erscheinungsbild des Prozessors bei 32bit-Implementationen und 64bit-Implementationen nicht unterscheidet (mit Ausnahme der größeren Breite der Register und zwei Befehlen, mit denen Daten in bzw. aus den oberen 32bit der Register bewegt werden können) wäre das auch möglich. Das würde auch zu der Aussage in den IBM-Dokus passen, dass jeder Kontextwechsel und jeder Interrupt den Prozessor sofort in den 64bit-Modus versetzt.
Außerdem passt das auch zu der Tatsache, dass der PowerPC schon von Anfang an als 64bit-Prozessor mit einer möglichen 32bit-Implementation geplant war, es also klar war, dass irgendwann einmal 32bit-Code existieren würde, der ohne Probleme auf einem 64bit-PPC laufen können sollte.
Also Mac OS X hat einen 32bit-Kernel, läuft aber trotzdem dauernd im 64bit-Modus. (Das scheint mir an plausibelsten, ich kann mich natürlich irren, ich lasse mich gerne mittels *Fakten* widerlegen.)
P.S.
Dazu noch ein Zitat aus der IBM-Dokumentation:
"The user-level instructions specific to the 64-bit PowerPC processors can be executed in both 32-bit and in 64-bit computation mode. The user-level instructions implemented by the 32-bit PowerPC processor can also be executed in either computation mode."
Es ist also egal, ob der Prozessor gerade im 32- oder 64bit-Modus läuft, es können immer alle 32- und 64-bit-Befehle ausgeführt werden.
"The kernel can be either 32- or 64-bit oriented."
Dabei ist es auch egal, ob der Kernel 32- oder 64bittig ist.
Das würde meine zuletzt geäußerte Vermutung bestätigen.
64bit beim x86/x64
Man kann von der 64bit-Implementierung bei x86/x64 nicht auf die 64bit-Implementierung des PPC schließen. Die beiden Unterscheiden sich grundsätzlich. Alles ist ausnahmslos unterschiedlich gelöst.
Im Gegensatz zum PowerPC unterscheidet sich beim x86/x86 (AMD64 bzw. Intel mit EMT64) im 64bit-Modus der Befehlssatz, der Prozessor ist ein anderer mit mehr Registern, anderen Addressmodi etc. Hier kann der kann den 64bit-Modus nur aktiviert werden, wenn der Kernel und alle Treiber 64bit sind, denn in Ring0 (in dem Kernel und Treiber laufen) kann nicht in den 32bit-Kompatibilität-Modus umgeschaltet werden.(Diese Leute nennen es beschönigend eine "Vorgabe von AMD". Dabei ist es schlicht eine Notwendigkeit. Aber das macht eh keinen Unterschied.) Ohne einen 64bit-Kernel läuft der Prozessor im 32bit i386-Modus.
Ergebnis: Ohne ein komplettes 64bit-System mit 64bit-Kernel und 64bit-Treibern kann kein 64bit-Code laufen.
Und wenn der 64bit-Kernel läuft, läuft kein einziger 32bit-Treiber mehr.
Für Mac OS X bedeutet das, dass die neuen Pro-Macs nur dann mehr, als 4GB RAM incl. Grafik-Speicher verwenden können soll bzw. einzelne Prozesse mehr als 4GB virtuellen Adressraum verwenden können, muss der Kernel und die Treiber 64bit sein. Die vorhandenen 32bit-Treiber von Fremdherstellern funktionieren erst mal nicht mehr, bis eine 64bit-Version herausgegeben wird.
P.S.
Intel schreibt dazu:
"Note that a new 64-bit operating system and device drivers will be needed to access the 64-bit capabilities of the enhanced Xeon processors. 32-bit applications will need to be recertified for the 64-bit operating environment even if the software remains 32-bit."
Wenn die Pro Macs jetzt (also noch mit Tiger) kommen und 64bit können sollten, dann wäre eigentlich folgendes Scenario realistisch: Der Kernel und die Treiber von Apple sind 64bit, damit der Prozessor im 64bit-Modus läuft, die GUI bleibt aber 32bit, damit die i386-Programme laufen können. Dazu gibt es (wie beim Tiger für den G5) die libSystem in x64 für Background-Prozesse, die mehr, als 4GB Adressraum benötigen.
P.S.
Nachdem der MacPro jetzt erschienen ist, stellt es sich anders dar. Die vorhandenen Treiber scheinen zu funktionieren (jedenfalls habe ich nichts gegenteiliges gehört), es können aber offensichtlich trotzdem x86_64-Background-Prozesse (bisher nur Benchmarks) über die libSystem ausgeführt werden.
Wie das allerdings möglich ist, konnte ich noch nicht herausfinden. Laut Intel wäre das jedenfalls nicht möglich (siehe oben) und bei Apple beziehen sich Dokumentationen zum Thema 64bit immer noch nur auf den G5.
Alternativ könnte noch auf PAE gesetzt werden und eine Technik, die mehr, als 4GB virtuellen Adressraum ermöglicht. Damit würden dann dazu, dass die möglichen Leistungsverbesserungen durch x64 verschenkt werden, noch die Leistungseinbussen durch PAE. Wenn man dazu dann noch die Langsamkeit von Mac OS X bedenkt dürfte der Pro Mac dann unter Tiger etwa halb so schnell sein, wie unter Windows oder Linux (bzw. ein Drittel der Geschwindigkeit bei den einschlägigen Benchmarks).
P.S.
Bei Intel wird x86_64 bzw. IA-32e anders implementiert, als bei AMD. Es ist bei Intel eigentlich nur eine Erweiterung zum PAE. Zum Aktivieren des 64bit-Modus muss eine 5-Stufige Initialisierungs-Sequenz abgefahren werden. In dieser muss zuerst PAE aktiviert werden. Die verwendete Paging-Tabelle muss in den untersten 4GB liegen.
P.P.S.
Apple schreibt zu Leopard:
"Leopard erreicht die nächste Stufe bei 64-Bit-Computing und bietet dabei volle Leistung und Kompatibilität für vorhandene 32-Bit-Programme und -Treiber."
Beim PowerPC ist das selbstverständlich kein Problem (siehe oben).
Beim Intel-Mac würde das der Intel-Dokumentation widersprechen (siehe oben). Falls bei Leopard tatsächlich 32bit-Treiber in einem 64bit-Kernel laufen, müsste das laut Intel-Doku eigentlich zu einem "general protection fault" führen. Man wird sehen, ob und wie das möglich ist.
EFI
EFI ist kein BIOS-Nachfolger, sondern eine Interface für eine Firmware. Beim Intel heißt diese Firmware BIOS (auch wenn bestimmten Leuten das Wort BIOS nicht zu gefallen scheint).
In den Intel-Dokumenten wird das Wort BIOS verwendet. Dort gibt es zwei Arten von BIOS. Zum einen die BIOS-Firmware, die die Hardware so initialisiert, dass EFI lauffähig ist. Zum anderen das Legacy-BIOS. Das Legacy-BIOS ist eine EFI-Software, die das bekannte BIOS-Interface emuliert (das interne Interface für das Betriebssystem, nicht das User-Interface).
P.S.
Mittlerweile ist klar, dass jeder aktuelle Intel-Chipsatz ein EFI enthält. Dieses ist auch aktiviert, kann jedoch normalerweise nur über das Legacy-BIOS-Interface angesprochen werden.
Targed-Mode etc.
Dazu habe ich mich schon früher geäußert. Das hatte ich falsch eingeschätzt. Ich damals übersehen hatte, dass der EFI nicht nur als Bootloader fungieren kann, sondern auch als komplett eigenständiges Betiebssystem mit eigenen Hardware-Treibern und ausführbaren Programmen laufen kann. Damit sind dann auch so etwas, wie der Targed-Mode, der Boot-Manager und der Hardware-Check möglich. (Allerdings auf einer anderen Ebene, als beim PPC mit OpenFirmware. Das tut aber nichts zur Sache.)
Hier wird ja von manchen Leuten behauptet, ich würde Falschaussagen machen und Märchen verbreiten. Leider halten sich diese Leute nicht für nötig, sich näher mit dem Thema zu beschäftigen, um meine Aussagen mit Fakten zu widerlegen. Sie investieren ihre Zeit lieber darin, mich zu diffamieren.
Da ich mit diesem Post wieder zur Zielscheibe von konzertierten Trollaktionen werden dürfte werde ich mich an der folgenden "Diskussion" nicht beteiligen und bin wieder weg.
Zum Thema.
64bit beim PPC
Die IBM-Dokumente ignoriere ich nicht. (Als ich mich weigerte einen Link zum 3D-Forum zu klicken, konnte ich ja nicht wissen, dass dort - nach Monaten Diskussion - endlich mal eine IBM-Dokumentation konsultiert wurde. Die hatte ich allerdings schon vor Jahren überflogen.) Die IBM-Dokumente werden von den 3D-Forums-Leuten so interpretiert, dass sie daraus lesen können: "._ut redet gerade Müll".
In den IBM-Dokumenten steht, dass es einen 32bit-Modus gibt.
Jetzt gibt es mehrere mögliche Interpretationen, wie Mac OS X die Modi behandelt.
Interpretation der 3D-Foren-Leute:
Der Kernel muss 64bit sein. Denn sonst kann der 64bit-Modus nicht eingeschaltet werden (diese Leute kennen nur x86/x64, da ist das so.)
Dem widersprechen aber verschiedene Dinge.
Zum einen sind die Treiber 32bit. In der Doku spricht IBM davon, dass das zwischen den Modi auf Per-Prozess-Basis gewechselt werden kann. Kernel und die Treiber sind bei Mac OS X aber ein einziger Prozess. Wenn also di Treiber 32bit sind, kann der Kernel nicht 64bit sein.
Das bestätigt sich auch, wenn man sich den Kernel anschaut, der ist keine ppc/ppc64-Universal-Binary (bzw. Fat-Binary), sondern eine flat-PPC-Binary. Auch die Apple-Dokumente sprechen davon, dass der Kernel nicht 64bit sein müsse. (Diese Dokumente werden von den 3D-Foren-Typen als Propaganda abgetan.)
Aus der Interpretation der 3D-Foren-Leute würde sich zwangsläufig ergeben, dass 32- und 64bit-Code innerhalb eines Prozesses gemischt werden kann. (Diese Leuten, die nur x86/x64 kennen, müssten hier eigentlich wieder schreien: Das ist nicht möglich.)
Möglich wäre das nur, wenn im 64bit-Modus auch 32bit-Code läuft (der 32bit-Modus also gar nicht verwendet wird). Das geht nicht, wenn die Modi umgeschaltet werden *müssen*.
Wie man sieht ist diese Interpretation voller Widersprüche. (Was aber nicht stört, denn sie bestätigt ja das wichtigste und umumstößliche Faktum: "._ut redet Müll"
Meine Interpretation der Sache sieht folgendermaßen aus:
Der 32bit-Modus wird von Mac OS X überhaupt nicht benutzt. Da sich beim PowerPC der Befehlssatz und das Erscheinungsbild des Prozessors bei 32bit-Implementationen und 64bit-Implementationen nicht unterscheidet (mit Ausnahme der größeren Breite der Register und zwei Befehlen, mit denen Daten in bzw. aus den oberen 32bit der Register bewegt werden können) wäre das auch möglich. Das würde auch zu der Aussage in den IBM-Dokus passen, dass jeder Kontextwechsel und jeder Interrupt den Prozessor sofort in den 64bit-Modus versetzt.
Außerdem passt das auch zu der Tatsache, dass der PowerPC schon von Anfang an als 64bit-Prozessor mit einer möglichen 32bit-Implementation geplant war, es also klar war, dass irgendwann einmal 32bit-Code existieren würde, der ohne Probleme auf einem 64bit-PPC laufen können sollte.
Also Mac OS X hat einen 32bit-Kernel, läuft aber trotzdem dauernd im 64bit-Modus. (Das scheint mir an plausibelsten, ich kann mich natürlich irren, ich lasse mich gerne mittels *Fakten* widerlegen.)
P.S.
Dazu noch ein Zitat aus der IBM-Dokumentation:
"The user-level instructions specific to the 64-bit PowerPC processors can be executed in both 32-bit and in 64-bit computation mode. The user-level instructions implemented by the 32-bit PowerPC processor can also be executed in either computation mode."
Es ist also egal, ob der Prozessor gerade im 32- oder 64bit-Modus läuft, es können immer alle 32- und 64-bit-Befehle ausgeführt werden.
"The kernel can be either 32- or 64-bit oriented."
Dabei ist es auch egal, ob der Kernel 32- oder 64bittig ist.
Das würde meine zuletzt geäußerte Vermutung bestätigen.
64bit beim x86/x64
Man kann von der 64bit-Implementierung bei x86/x64 nicht auf die 64bit-Implementierung des PPC schließen. Die beiden Unterscheiden sich grundsätzlich. Alles ist ausnahmslos unterschiedlich gelöst.
Im Gegensatz zum PowerPC unterscheidet sich beim x86/x86 (AMD64 bzw. Intel mit EMT64) im 64bit-Modus der Befehlssatz, der Prozessor ist ein anderer mit mehr Registern, anderen Addressmodi etc. Hier kann der kann den 64bit-Modus nur aktiviert werden, wenn der Kernel und alle Treiber 64bit sind, denn in Ring0 (in dem Kernel und Treiber laufen) kann nicht in den 32bit-Kompatibilität-Modus umgeschaltet werden.(Diese Leute nennen es beschönigend eine "Vorgabe von AMD". Dabei ist es schlicht eine Notwendigkeit. Aber das macht eh keinen Unterschied.) Ohne einen 64bit-Kernel läuft der Prozessor im 32bit i386-Modus.
Ergebnis: Ohne ein komplettes 64bit-System mit 64bit-Kernel und 64bit-Treibern kann kein 64bit-Code laufen.
Und wenn der 64bit-Kernel läuft, läuft kein einziger 32bit-Treiber mehr.
Für Mac OS X bedeutet das, dass die neuen Pro-Macs nur dann mehr, als 4GB RAM incl. Grafik-Speicher verwenden können soll bzw. einzelne Prozesse mehr als 4GB virtuellen Adressraum verwenden können, muss der Kernel und die Treiber 64bit sein. Die vorhandenen 32bit-Treiber von Fremdherstellern funktionieren erst mal nicht mehr, bis eine 64bit-Version herausgegeben wird.
P.S.
Intel schreibt dazu:
"Note that a new 64-bit operating system and device drivers will be needed to access the 64-bit capabilities of the enhanced Xeon processors. 32-bit applications will need to be recertified for the 64-bit operating environment even if the software remains 32-bit."
Wenn die Pro Macs jetzt (also noch mit Tiger) kommen und 64bit können sollten, dann wäre eigentlich folgendes Scenario realistisch: Der Kernel und die Treiber von Apple sind 64bit, damit der Prozessor im 64bit-Modus läuft, die GUI bleibt aber 32bit, damit die i386-Programme laufen können. Dazu gibt es (wie beim Tiger für den G5) die libSystem in x64 für Background-Prozesse, die mehr, als 4GB Adressraum benötigen.
P.S.
Nachdem der MacPro jetzt erschienen ist, stellt es sich anders dar. Die vorhandenen Treiber scheinen zu funktionieren (jedenfalls habe ich nichts gegenteiliges gehört), es können aber offensichtlich trotzdem x86_64-Background-Prozesse (bisher nur Benchmarks
) über die libSystem ausgeführt werden. Wie das allerdings möglich ist, konnte ich noch nicht herausfinden. Laut Intel wäre das jedenfalls nicht möglich (siehe oben) und bei Apple beziehen sich Dokumentationen zum Thema 64bit immer noch nur auf den G5.
Alternativ könnte noch auf PAE gesetzt werden und eine Technik, die mehr, als 4GB virtuellen Adressraum ermöglicht. Damit würden dann dazu, dass die möglichen Leistungsverbesserungen durch x64 verschenkt werden, noch die Leistungseinbussen durch PAE. Wenn man dazu dann noch die Langsamkeit von Mac OS X bedenkt dürfte der Pro Mac dann unter Tiger etwa halb so schnell sein, wie unter Windows oder Linux (bzw. ein Drittel der Geschwindigkeit bei den einschlägigen Benchmarks).
P.S.
Bei Intel wird x86_64 bzw. IA-32e anders implementiert, als bei AMD. Es ist bei Intel eigentlich nur eine Erweiterung zum PAE. Zum Aktivieren des 64bit-Modus muss eine 5-Stufige Initialisierungs-Sequenz abgefahren werden. In dieser muss zuerst PAE aktiviert werden. Die verwendete Paging-Tabelle muss in den untersten 4GB liegen.
P.P.S.
Apple schreibt zu Leopard:
"Leopard erreicht die nächste Stufe bei 64-Bit-Computing und bietet dabei volle Leistung und Kompatibilität für vorhandene 32-Bit-Programme und -Treiber."
Beim PowerPC ist das selbstverständlich kein Problem (siehe oben).
Beim Intel-Mac würde das der Intel-Dokumentation widersprechen (siehe oben). Falls bei Leopard tatsächlich 32bit-Treiber in einem 64bit-Kernel laufen, müsste das laut Intel-Doku eigentlich zu einem "general protection fault" führen. Man wird sehen, ob und wie das möglich ist.
EFI
EFI ist kein BIOS-Nachfolger, sondern eine Interface für eine Firmware. Beim Intel heißt diese Firmware BIOS (auch wenn bestimmten Leuten das Wort BIOS nicht zu gefallen scheint).
In den Intel-Dokumenten wird das Wort BIOS verwendet. Dort gibt es zwei Arten von BIOS. Zum einen die BIOS-Firmware, die die Hardware so initialisiert, dass EFI lauffähig ist. Zum anderen das Legacy-BIOS. Das Legacy-BIOS ist eine EFI-Software, die das bekannte BIOS-Interface emuliert (das interne Interface für das Betriebssystem, nicht das User-Interface).
P.S.
Mittlerweile ist klar, dass jeder aktuelle Intel-Chipsatz ein EFI enthält. Dieses ist auch aktiviert, kann jedoch normalerweise nur über das Legacy-BIOS-Interface angesprochen werden.
Targed-Mode etc.
Dazu habe ich mich schon früher geäußert. Das hatte ich falsch eingeschätzt. Ich damals übersehen hatte, dass der EFI nicht nur als Bootloader fungieren kann, sondern auch als komplett eigenständiges Betiebssystem mit eigenen Hardware-Treibern und ausführbaren Programmen laufen kann. Damit sind dann auch so etwas, wie der Targed-Mode, der Boot-Manager und der Hardware-Check möglich. (Allerdings auf einer anderen Ebene, als beim PPC mit OpenFirmware. Das tut aber nichts zur Sache.)
Zuletzt bearbeitet von einem Moderator:
D
Dr. NoPlan
@._ut
tu mir den Gefallen und hau nicht wieder ab!
tu mir den Gefallen und hau nicht wieder ab!
B
Badener
Dr. NoPlan schrieb:@._ut
tu mir den Gefallen und hau nicht wieder ab!
Uneingeschränkte Zustimmung meinerseits (wenn auch OT)
-Nuke-
Aktives Mitglied
- Dabei seit
- 13.09.2003
- Beiträge
- 2.146
- Reaktionspunkte
- 15
._ut schrieb:
Dein Verhalten war entsprechend. Deine Worte auf die IBM-Doku waren einfach "Die lese ich nicht". Fertig aus. Danach warst du auch schon weg...
._ut schrieb:
Jetzt sag nicht das du das von Anfang an wusstest. Das hast du erst durch den Thread gelernt. Vorher war deine Aussage: "32bit und 64bit Nebeneinander geht auf x86 nicht". Was du natürlich später wieder abgestitten hast und deine Meinung geändert hast, wie so oft.
Vorgabe von AMD oder "Notwendigkeit". Du nimmst dir halt das was dir jetzt gerade besser gefällt.
Denn wenn du es so nimmst ist x86 wie auch PowerPC heute auch nur ein Interface auf eine Hersteller-Eigene Archtektur. Bei beiden ist nichts "unmöglich".
._ut schrieb:
Ja und jetzt lerne programmieren. Dann merkst du das diese Art der pure Wahnsinn ist. Das macht kein Programmierer, der ein fertiges Produkt konvertieren möchte. Und selbst für Neuprojekte ist diese Art sehr teuer.
Mit dieser Methode wirst du NIE (!!!) große Produkte wie CInema4D, Maya, FinalCut, Photoshop etc. in einer 64bit-Verison sehen. Dann ist OS X irgendwann das "alte 32bit-System". Unter Windows würdest du es nur etwas tweaken und dann als 64bit-Version kompilieren und hättest Zugriff auf den kompletten Speicher. Unter OS X musst du dazu quasi das ganze Programm neu schreiben. Wie gesagt. Das macht keiner. Da kann Apple noch so oft sagen das eine 64bit-GUI unnütz ist.
Das Resultat daraus ist schlicht, das sämtliche 32bit/64bit-Mixturen nur ein Übergang sind. Ein komplettes 64bit-OS X ist einfach nötig und somit sämtliche Vorteile (bzw. der eine Vorteil) des ppc64-Modus hinfällig. Ansonsten zischen Systeme wie Windows und Linux an OS X vorbei. Denn das ist momentan der Fall. Wobei das bei Windows sogar eleganter ist mit WoW64. Sogar noch eleganter als Universal Binarys.
Hier trifft sich Theorie und Praxis. Da mag die Theorie noch so gut sein. Die Praxis funktioniert anders.
._ut schrieb:
Im Endeffekt bezeichne ich dann auch die OpenFirmware als BIOS. Denn EFI ist nix anderes in der gesamten Ansicht. Nur halt das das CLI-Interface der OpenFirmware keinen besonderen Namen hat...
edit:
Achja. Und nur weil du deine etwas korrigierten Aussagen jetzt noch mal so hier schreibst, als hättest du das schon immer behauptet, ist auch nicht die feine Art, denke ich zumindest. Aber wie man merkt hast du ja deine Fans hier, die dich anhimmeln.
Zuletzt bearbeitet:
Wie lange gibt es jetzt OS X als x86/32bit-Version?._ut schrieb:
"Offiziell" 1 Jahr.
Dann wird halt irgendwann neu entwickelt. Es ist ja nicht so, als gäbe es schon ewig viel 32-bittige "Legacy-Treiber" - und das betrifft ja nur die im Kernelspace...
Wo ist der Unterschied?._ut schrieb:
-Nuke-
Aktives Mitglied
- Dabei seit
- 13.09.2003
- Beiträge
- 2.146
- Reaktionspunkte
- 15
Wobei ich denke, das dank KPI und IOKit der Portierungsaufwand in einem erträglichen Rahmen bleibt. Gemacht werden muss er so oder so, egal ob x86 oder PowerPC. Erklärung dazu hab ich ja weiter oben schon gegeben.
Zuletzt bearbeitet:
Angel
Aktives Mitglied
- Dabei seit
- 30.06.2003
- Beiträge
- 7.503
- Reaktionspunkte
- 237
Ich himmel ihn nicht an, finde es aber schade, wenn so ein kompetenter User geht. Er hat ohne Frage ein riesiges technisches Wissen und es ist sehr interessant, seine Posts zu lesen (auch wenn ich nicht alles verstehe).-Nuke- schrieb:Aber wie man merkt hast du ja deine Fans hier, die dich anhimmeln.
Ich fänds genauso schade, wenn du oder Performa gingest. Auch wenn ihr euch in euren Diskussionen häufig im Kreis dreht, kann man immer etwas lernen, ausserdem ist es eine schöne Abwechslung zum sonstigen, recht oberflächlichen Einheitsbei.
Das ist oft das Problem, wenn man viel weiß!
Dann tut man sich oftmals schwer kleine Fehlerchen einzugestehen...ich weiß nicht wieso das so ist, aber ich kenn das von mir selbst, v.a. wenn ich mit Leuten rede die ich für weniger gebildet halte...
Dann tut man sich oftmals schwer kleine Fehlerchen einzugestehen...ich weiß nicht wieso das so ist, aber ich kenn das von mir selbst, v.a. wenn ich mit Leuten rede die ich für weniger gebildet halte...
schdeffan schrieb:
ähnl. mache ich das auch. was nützt mir die diskussion ppc od. intelmac.
ich möcht einfach nur nen rechner, der funktioniert und wenn er das leise und schnell tut, dann hab ich fast keine wünsche mehr.
schdeffan schrieb:
aber da arbeiten sie doch dran. die neue version soll es in ub geben, so sagt es die website ;o)
http://www.adobe.com/de/products/creativesuite/
-Nuke-
Aktives Mitglied
- Dabei seit
- 13.09.2003
- Beiträge
- 2.146
- Reaktionspunkte
- 15
Jups. Aufgrund des schlampigen OS X-Ports waren sie eine der ersten mit einer OS X-Version, weil die Konkurrenz-Produkte einen guten Port machen wollten.
Ausgleichende Gerechtigkeit. Jetzt sind die damals Letzten die Ersten und die damals Ersten die Letzten.
Ausgleichende Gerechtigkeit.
Jetzt sind die damals Letzten die Ersten und die damals Ersten die Letzten. 
steve_cooks
Aktives Mitglied
- Dabei seit
- 17.02.2006
- Beiträge
- 3.070
- Reaktionspunkte
- 116
Ohne jetzt den ganzen Fred gelesen zu haben: Solange so immanente Software wie Adobes Creative Suite nicht UB sind, kann die Antwort ja nur lauten: PPC!