Nutzt Apple Intel-CPU-Bugs aus? [Archiv]

Neuer Macuser

2007-11-10, 15:26:13

Gefunden... hier einige Ausschnitte:

"Im i386-Kernel von Mac OS X sind aber ein paar ziemlich üble Hacks eingebaut, mit Ignorieren von Hardware-Exceptions, Auslesen von Registern, die in dem Mode lauft Doku gar nicht ausgelesen werden können etc., d.h. Ausnutzen von Bugs in der Implementation, die unter Intel irgendwie möglich machen, was unter PPC einfach so geht, weil es so vorgesehen ist: Es läuft ein 32bit-Kernel, obwohl der Prozessor eigentlich im 64bit-Modus läuft. 64 bit-Programme können im Userspace laufen, trotz 32-bit-Kernel."

"Die Kommentare in den Kernel-Sourcen sind sehr aufschlussreich. Den Kernel-Entwicklern bei Apple muss man auf jeden Fall Anerkennung zollen. Die haben das Beste aus der Fehlentscheidung ihres CEO gemacht. Die haben es irgendwie geschafft, den Kernel so laufen zu lassen, wie es eigentlich nur auf dem PPC möglich ist. Sogar die hierarchischen Device-Strukturen des PPC werden da nachgebaut (ein fakePPCDeviceTree).
Es ist übrigens kein 32/64bit-Mischbetrieb, es läuft bei eingeschaltetem Long-Mode ein 32bit-Kernel im Compatibility-Mode.

Die Bugs in der Implementation, die Apple hier ausnutzt, um den Kernel in den für User-Prozesse reservierten Compatibility-Mode zu schieben, scheinen ja übergreifend vorhanden zu sein. Mac OS X läuft ja nicht nur auf Intel, sondern auch auf AMD-CPUs.

Einerseits denke ich, dass diese Bugs in der Implementation irgendwann ausgeräumt werden müssen. Das ist sicherlich auch eine potenzielle Sicherheitslücke, wenn man Kernel-Code im schlechter gesicherten Compatibility-Mode ausführen kann. Auf Apple wird Intel da jedenfalls kein Rücksicht nehmen. Andererseits denke ich, dass die dass diese Bugs in der Implementation nicht ausgeräumt werden. Bislang hat Intel noch jeden Fehler in der ISA über Generationen mitgeschleppt.

Apple wird sicherlich in der nächsten (oder einer der nächsten) Version von Mac OS X auf einen 64 bit Kernel umschwenken. Das hat zwar zur Folge, dass der Kunde mal wieder alle seine vorhandene Hardware einstampfen kann, da es dafür dann keine Treiber gibt. Aber da hat sich Apple bekanntlich noch nie drum geschert."

Superguppy

2007-11-10, 16:03:30

Finde ich interessant ... wenn du es in der History gefunden hast, kannst du dann auch den Link hier rein stellen? :)

Tommes

2007-11-10, 16:09:49

http://www.ppcnux.de/?q=node/7105

Google ftw

Gast

2007-11-10, 23:25:57

Die Bugs in der Implementation, die Apple hier ausnutzt, um den Kernel in den für User-Prozesse reservierten Compatibility-Mode zu schieben, scheinen ja übergreifend vorhanden zu sein. Mac OS X läuft ja nicht nur auf Intel, sondern auch auf AMD-CPUs.

Und das ist der Punkt ;) Ich denke nicht, dass beide Hersteller exakt die gleichen Fehler in ihre CPUs einbauen und die auch genau gleich ausgenutzt werden können. Da zumal das ganze von PPCNUX stammt, hat es eh jegliche Bedeutung verloren :p

Mailwurm

2007-11-11, 01:26:02

Wenn es um 64 Bit geht gilt: Was bei Intel gilt, wird auch bei AMD gehen und umgekehrt.

Es liegt einfach daran, dass AMD die 64-Bit-Erweiterung AMD64 aka x86-64 entwickelt hat und Intel sie im Rahmen des Technologieaustauschs beider Firmen lizenziert hat (AMD darf dafür bspw. SSE nutzen). Bei Intel heißt sie halt nur Intel64, aber technisch sind sie absolut identisch. Bei zwei unterschiedlichen Implementierungen müssten die Programmierer jede Software doppelt schreiben und 64 Bit würde sich noch langsamer / gar nicht durchsetzen.

Abgesehen davon versteh ich die künstliche Aufregung von PPCNUX nicht. Der Compatibility-Modus ist ein ganz normaler Bestandteil des Long Mode und was spricht gegen Apple ihn zu nutzen? Ich wette wenn man den Linux- oder Windows-Kernel durchforsten würde, fände man auch einige fragwürdige Konstruktionen. Solang das System damit stabil läuft -who cares?

sth

2007-11-11, 01:37:43

http://www.ppcnux.de/...
Ach die schon wieder... ;D
Ja ja... mit PowerPC war alles besser...

Legolas

2007-11-11, 01:43:40

Wenn es um 64 Bit geht gilt: Was bei Intel gilt, wird auch bei AMD gehen und umgekehrt.

Es liegt einfach daran, dass AMD die 64-Bit-Erweiterung AMD64 aka x86-64 entwickelt hat und Intel sie im Rahmen des Technologieaustauschs beider Firmen lizenziert hat (AMD darf dafür bspw. SSE nutzen). Bei Intel heißt sie halt nur Intel64, aber technisch sind sie absolut identisch. Bei zwei unterschiedlichen Implementierungen müssten die Programmierer jede Software doppelt schreiben und 64 Bit würde sich noch langsamer / gar nicht durchsetzen.

Wirklich?

http://en.wikipedia.org/wiki/X86-64#Differences_between_AMD64_and_Intel_64

100% identisch sind sie wohl nicht.

Mailwurm

2007-11-11, 22:12:50

Wirklich?

http://en.wikipedia.org/wiki/X86-64#Differences_between_AMD64_and_Intel_64

100% identisch sind sie wohl nicht.

Doch für die Programmierer. Steht ja auch da da dies in den Compilern bereits berücksichtigt ist. Wenn Du es darauf anlegst, dann sind alle derzeit aktuellen x86er CPUs gar keine, weil sie alle über Bugs verfügen und so nach deiner Ansicht nicht mehr 100% identisch zur x86er-Architektur sind. Das ist aber Quark. Wenn Du eine Anwendung compilierst für x86 mit 64 Bit, dann wird sie auf allen CPUs laufen, die diese Features haben.

Legolas

2007-11-11, 23:40:52

Doch für die Programmierer. Steht ja auch da da dies in den Compilern bereits berücksichtigt ist. Wenn Du es darauf anlegst, dann sind alle derzeit aktuellen x86er CPUs gar keine, weil sie alle über Bugs verfügen und so nach deiner Ansicht nicht mehr 100% identisch zur x86er-Architektur sind. Das ist aber Quark. Wenn Du eine Anwendung compilierst für x86 mit 64 Bit, dann wird sie auf allen CPUs laufen, die diese Features haben.

Wenn es aber um Dinge geht, die nicht in der Spezifikation vorgesehen sind, also im Prinzip um Bugs(steht ja auch im Threadtitel), wieso sollten die dann bei alles CPU Typen gleich sein. Die müssten dann ja in sämtlichen K8 Varianten, dem PIV mit x64 und dem aktuellen Core 2 Duo vorhanden sein. Wenn schon die eigentliche Spezifikation nicht 100% identisch von beiden großen Herstellern implementiert wird, wieso sollte sie dann bei nicht spezifiziertem Verhalten identisch sein?

Mailwurm

2007-11-11, 23:47:19

Wer sagt denn, dass es sich wirklich um Bugs handelt? PPCNUX schreibt viel, wenn es deren vorgefertigte Meinung bestätigt, dass Intel grundsätzlich Scheiße ist und PowerPC die Göttlichkeit an System-Architekturen. Ich kann es nicht beurteilen, dazu fehlt mir das Wissen. Ich bezweifle aber, dass so ist, wie PPCNUX schreibt. Das wäre wenn dann schon ganz anderen Leuten aufgefallen, bspw. Amit Singh, der ein Buch über die Interna von Mac OS X geschrieben hat.

Siehe: http://www.osxbook.com http://www.kernelthread.com

Legolas

2007-11-12, 00:06:19

Falls die Behauptungen von PPCNUX stimmen, wäre das glaube schon ein Bug, weil afaik von 32bit Code, der im Compatibility Mode des 64bit Modus läuft, keine privilegierten Instruktionen ausgeführt werden können. Ohne diese, kann man aber kein OS wie Mac OS X bauen.

Gast

2007-11-13, 11:26:23

Hmmm

"

Nee, so kann man das nicht sagen. Eher könnte man sagen: Der Kernel läuft in einem Modus, den es eigentlich gar nicht geben darf.
Er läuft im Kernel-Modus des Compatibility-Modus. Den gibt es, weil der Compatibility-Modus identisch mit dem 32-bit-Modus innerhalb des Legacy-Modus ist (auf gut deutsch ein x86 ohne die 16bit-Segment-Adressierung). Der Zugang dazu ist aber eigentlich durch eine Hardware Exception gesperrt. Apple schafft es aber trotzdem Code in diesem Modus auszuführen.

Außerdem, das ist nichts neues. Das gibt es so seit Einführung des ersten Intel-"Macs" mit 64bit-Erweiterung (MacPro, August 2006). Die Sourcen, die von denen ich rede, sind die vom 10.4-Kernel, im 10.5-Kerle hat sich aber eh nichts geändert."

"Dass da intern Saltos gemacht werden müssen, da hast Du allerdings recht. Wenn Du mal Zeit hast, lad Dir einfach mal die Kernel-Sourcen bei Apple und lies Dir die Kommentare darin durch. Das ist sehr interessant."

Neugierig

2007-11-16, 15:52:26

Ja, wie funktioniert das denn jetzt nun?

DR.ZEISSLER

2007-11-19, 20:46:47

liest sich so, als ob PPC besser war als x86 ?!?

Doc

Senior Sanchez

2007-11-19, 21:04:21

liest sich so, als ob PPC besser war als x86 ?!?

Doc

Bei PPCNUX? Man achte auf die Domain ;)

-Phoenix-

2007-11-19, 21:53:38

Bei PPCNUX? Man achte auf die Domain ;)

Doch nicht bei PPCNUX :eek:
Die schreiben doch immer so wunderschön objektive Artikel über den Intel Switch! :cool:

Wer Ironie findet darf sie behalten... *scnr*

Mfg

Gast

2007-11-20, 12:26:53

Bei PPCNUX? Man achte auf die Domain ;)
Ändert nichts an der Tatsache, dass PPC besser als x86 ist!

DR.ZEISSLER

2007-11-20, 13:01:25

Ändert nichts an der Tatsache, dass PPC besser als x86 ist!

bitte belegen!
wo ist ppc besser und warum ?
- schlußendlich ist der x86 aufgrund der höheren "züchtung" besser ?
- im direkten vergleich unterliegt er vielleicht ?
- in wie weit kann man von optimierten x86 oder ppc-code sprechen ?

Doc

Gast

2007-11-20, 14:02:40

bitte belegen!

Die ganze Architektur ist besser und viel moderner. PowerPC ist von Anfang an als 64Bit System gedacht gewesen (beim G4 mit 32Bit Subsystem).

Das hat erstmal nichts mit der Weiterentwicklung und Geschwindigkeit zu tun. Hier liegt x86 nur vorne, weil es halt von Windows genutzt wird und praktisch jeder daheim einen x86 hat (und nicht weil x86 besser ist oder so).

DR.ZEISSLER

2007-11-20, 18:25:55

Ok, dann mal für 'nen laien mit eigenen worten.

x86 01010101010
PPC 01010101010

Also wo GENAU ist der Unterschied in 1-2 verständlichen Sätzen.

Danke
Doc

StefanV

2007-12-09, 14:32:27

Ändert nichts an der Tatsache, dass PPC besser als x86 ist!
Nö, nicht wirklich...

Ganz ab davon ist ein 32bittiger Benzium 3 unter Vista schneller als ein 933er G4 mit 2MiB Backsidecache unter OSX 10.4.9, wo alles doch irgendwie sehr zäh ist, hakt und Stockt...

Gast

2007-12-09, 14:45:18

Nö, nicht wirklich...

Ganz ab davon ist ein 32bittiger Benzium 3 unter Vista schneller als ein 933er G4 mit 2MiB Backsidecache unter OSX 10.4.9, wo alles doch irgendwie sehr zäh ist, hakt und Stockt...
Die PPC-Architektur ist moderner und besser. Damit hat "schneller" nichts zu tun.

Gast

2007-12-09, 14:50:39

als ein 933er G4 mit 2MiB Backsidecache unter OSX 10.4.9, wo alles doch irgendwie sehr zäh ist, hakt und Stockt...
Wieviel Ram? OSX braucht Ram!

Aber back to Topic!

mbee

2007-12-09, 14:54:17

Die PPC-Architektur ist moderner und besser.
Das ist IMO ziemlicher Schwachfug bzw. belege es doch einmal bitte ausführlicher: Was ist an der PPC-Architektur "besser", was "moderner"?
Wenn Du Dich dabei ausschließlich auf PPCNUX beziehst, weiß man, was man von den Aussagen halten muss ;)

Gast

2007-12-09, 14:57:07

Das ist IMO ziemlicher Schwachfug bzw. belege es doch einmal bitte ausführlicher: Was ist an der PPC-Architektur "besser", was "moderner"?
Wenn Du Dich dabei ausschließlich auf PPCNUX beziehst, weiß man, was man von den Aussagen halten muss ;)
moderner wirst du wohl nicht abstreiten können. und wenn die x86-architektur ebenbürtig ist, wirst du vielleicht die fragestellung des threads erklären können oder?

mbee

2007-12-09, 15:04:12

moderner wirst du wohl nicht abstreiten können. und wenn die x86-architektur ebenbürtig ist, wirst du vielleicht die fragestellung des threads erklären können oder?
Du würfelst hier einiges durcheinander: Dass Apple einen "Hack" benutzt, liegt einzig und alleine an der Art der Implementierung von OSX bzw. Darwin und hat so mit der "Ebenbürtigkeit" oder "Leistungsfähigkeit" der Prozessorarchitektur nichts zu tun (wurde in diesem Thread ja schon erklärt).

Definiere "moderner" bitte. Wenn Du das mit "noch nicht so lange am Markt" übersetzen möchtest, trifft das sicherlich zu. Mit der Leistungsfähigkeit der Architektur hat das allerdings wiederum nichts zu tun. Und bitte nicht wieder diese altbackene CISC-RISC-Debatte lostreten, da diese Bezeichnungen auf diese Prozessoren eigentlich eh nicht mehr anzuwenden sind.

Gast

2007-12-09, 15:33:32

Du würfelst hier einiges durcheinander: Dass Apple einen "Hack" benutzt, liegt einzig und alleine an der Art der Implementierung von OSX bzw. Darwin und hat so mit der "Ebenbürtigkeit" oder "Leistungsfähigkeit" der Prozessorarchitektur nichts zu tun (wurde in diesem Thread ja schon erklärt).

Beim PPC muss Apple hingegen keinen Hack nutzen. Also! ;)

Gast

2007-12-09, 15:48:04

(wurde in diesem Thread ja schon erklärt).

Ich sehe nicht, wo was geklärt ist, ausser das kaum jemand gewillt ist, mögliche Nachteile und Defizite der x86-Architektur gegenüber anderen Architekturen einzugestehen.

Und das bei PowerPC bei der Entwicklung schon an 64Bit gedacht wurde und es daher nur eine ISA gibt, mit einem 32bit Subset ist nicht besser als bei x86, wo es einmal IA32 gibt und dann wieder AMD64, mit einer gewissen Schnittmenge?

mbee

2007-12-09, 15:58:35

Ich sehe nicht, wo was geklärt ist, ausser das kaum jemand gewillt ist, mögliche Nachteile und Defizite der x86-Architektur gegenüber anderen Architekturen einzugestehen.

Und das bei PowerPC bei der Entwicklung schon an 64Bit gedacht wurde und es daher nur eine ISA gibt, mit einem 32bit Subset ist nicht besser als bei x86, wo es einmal IA32 gibt und dann wieder AMD64, mit einer gewissen Schnittmenge?

OMF, natürlich gibt es auch Nachteile der x86-Architektur gegenüber PPC wie den von Dir erwähnten. Andersrum sieht's allerdings genau so aus oder warum musste Apple die letzten G5 super aufwändig übertakten, damit diese nur halbwegs mit modernen X86-Prozessoren mithalten konnten? Warum sieht Altivec z.B. gegen SSE4 kein Land?
Es ist nicht alles derart schwarz-weiss und solche Aussagen wie "PPC ist eh moderner, besser, schneller, die tollste Schwanzverlängerung" sind genau so daneben wie Aussagen in dieser Richtung bezüglich x86...

Gast

2007-12-09, 16:07:33

OMF, natürlich gibt es auch Nachteile der x86-Architektur gegenüber PPC wie den von Dir erwähnten. Andersrum sieht's allerdings genau so aus oder warum musste Apple die letzten G5 super aufwändig übertakten, damit diese nur halbwegs mit modernen X86-Prozessoren mithalten konnten?
Apple hat nichts übertaktet. Die CPU gab es offiziell von IBM. Mal daran gedacht, dass solchen "Geschwindigkeitsvergleiche" andere Gründe haben? In x86 wird halt mehr Geld reingesteckt und da gibt es den direkten Kampf zwischen Intel vs. Amd. Das hat aber nichts mit der eigentlichen Architektur zu tun!

Und durch den Switch wurde deutlich, dass der G5 vom Speed her vor den x86 lag. Aber wenn man sich vom Marketing blenden lässt und im allgemeinen PPC-ist-lahm-Strom schwimmt, ohne mal selber zu vergleichen, kommt man nicht drauf. Die ganzen Benches damals, wurden meist zwischen Dual-Core (Yonah) und Single-Core (G5) durchgeführt. Wenn man hingegen Core gegen Core damals verglichen hat, lagen beide recht nahe beisamen, mit dem Unterschied, dass der Yonah ganz neu war, der G5 aber schon seit Ewigkeiten auf dem Markt ;) Aber wie gesagt, darum geht es mir nicht, sondern um die Architektur ansich.

Es ist nicht alles derart schwarz-weiss und solche Aussagen wie "PPC ist eh moderner, besser, schneller, die tollste Schwanzverlängerung" sind genau so daneben wie Aussagen in dieser Richtung bezüglich x86...
Du hast doch oben selber zugegeben, dass von der Architektur her PPC Vorteile hat, also?

Ich finde auch, dass die Jungs von ppcnux übertreiben. Aber wie hier immer generell alles von denen als Schwachsinn hingestellt wird, kann ich nicht ab. Denn da ist IMHO schon was wahres dran, wenn auch nicht so, wie von denen dargestellt!

Ganon

2007-12-09, 16:14:24

Apple hat nichts übertaktet. Die CPU gab es offiziell von IBM.

Nope. Einen 2,7Ghz G5 gab es von IBM damals nicht.

Wenn man hingegen Core gegen Core damals verglichen hat, lagen beide recht nahe beisamen, mit dem Unterschied, dass der Yonah ganz neu war, der G5 aber schon seit Ewigkeiten auf dem Markt ;)

Und PPC-Fanatiker übersehen dabei leider immer das Yonah nur ein Pentium M mit längerer Pipeline ist, welcher ähnlich alt wie der G5 ist. Weiter Punkt ist das Yonah eine NOTEBOOK(!!!)-CPU ist, der G5 hingegen schon in Desktops Temperaturprobleme verursacht. ;)

Gast

2007-12-09, 16:18:14

Nochmal....

OMF, natürlich gibt es auch Nachteile der x86-Architektur gegenüber PPC wie den von Dir erwähnten.
Vorteile der Architektur eben!

Andersrum sieht's allerdings genau so aus oder warum musste Apple die letzten G5 super aufwändig übertakten, damit diese nur halbwegs mit modernen X86-Prozessoren mithalten konnten?
Unabhängig vom Wahrheitsgehalt dieser Aussage, was hat das mit der Architektur ansich zu tun? Mit dem P4 hat Intel auch gegenüber AMD hinterhergehangen. Trotzdem ist ein P4 ein x86!

Warum sieht Altivec z.B. gegen SSE4 kein Land?
ROTFL - also noch frecher geht es nicht, mit dem Verdrehen der Wahrheit. SSE4 gibt es gerade mal seit kurzem, Altivec hingegen schon seit Jahren. Ausserdem ist Altivec AFAIK auch weiterentwickelt worden, mit Altive 2 bzw. wäre wohl ohne Switch gekommen.

Nope. Einen 2,7Ghz G5 gab es von IBM damals nicht.
Ich hatte mal einen Link zum Datenblatt bei IBM und da war wohl ein 2,7er AFAIF dabei. Bin mir aber nicht sicher. Und wie gesagt, darum geht es mir nicht!

Und PPC-Fanatiker übersehen dabei leider immer das Yonah nur ein Pentium M mit längerer Pipeline ist, welcher ähnlich alt wie der G5 ist. Weiter Punkt ist das Yonah eine NOTEBOOK(!!!)-CPU ist, der G5 hingegen schon in Desktops Temperaturprobleme verursacht.
Du kannst aber nicht abstreiten, dass der G5 im Vergleich zu Yonah alt ist. Ausserdem hat sich der G5 Quad ziemlich gut gegen Mac Pro behauptet, der viel neuer ist.

Mit der PPC-Architektur hätte man mit Garantie auch viel bessere CPUs auf die Beine stellen können. Das es dazu nicht mehr kam, hängt an anderen Gründen, als an der eigentlichen Architektur -> um die es hier geht.

Ganon

2007-12-09, 16:24:44

ROTFL - also noch frecher geht es nicht, mit dem Verdrehen der Wahrheit. SSE4 gibt es gerade mal seit kurzem, Altivec hingegen schon seit Jahren. Ausserdem ist Altivec AFAIK auch weiterentwickelt worden, mit Altive 2 bzw. wäre wohl ohne Switch gekommen.

Altivec wurde nur in der Performance beim G4 aufgebohrt und beim G5 wurde Altivec noch mal stark kastriert. Altivec2? Naja, wie man es nimmt. In der XBOX360 vllt. im Ansatz zu finden, leider nicht wirklich im Alltag nutzbar -> hatten wir schon in anderen Threads...

Ich hatte mal einen Link zum Datenblatt bei IBM und da war wohl ein 2,7er AFAIF dabei.

Nope.

Du kannst aber nicht abstreiten, dass der G5 im Vergleich zu Yonah alt ist.

Noch mal. Yonah IST ein Pentium M (mit 2 Kernen). Der erste PPC970 kam Ende 2002. Der Pentium M kam Anfang 2003 (und hielt damals als Notebook CPU schon mit dem G5 mit ;))

Ausserdem hat sich der G5 Quad ziemlich gut gegen Mac Pro behauptet, der viel neuer ist.

Teste mal nicht unter OS X Tiger, sondern unter Leopard oder Linux. Systeme, welche nicht "mal fix auf x86" umgestellt wurden ;)

Mit der PPC-Architektur hätte man mit Garantie auch viel bessere CPUs auf die Beine stellen können.

Klar, TokenRing hätte man auch schneller bekommen, wenn man weiter daran gearbeitet hätte.

Gast

2007-12-09, 16:28:00

Ganon, da bin ich nicht überall deiner Meinung. Aber das ist auch egal, da das nichts mit der Frage zur eigentlichen Architektur zu tun hat.

Und schon garnicht, mit der Frage des Threaderstellers!

mbee

2007-12-09, 16:29:29

Unabhängig vom Wahrheitsgehalt dieser Aussage, was hat das mit der Architektur ansich zu tun? Mit dem P4 hat Intel auch gegenüber AMD hinterhergehangen. Trotzdem ist ein P4 ein x86!
Die Aussage ist wahr, Du brauchst nur ein wenig Google zu bemühen oder genauer bei IBM zu recherchieren.
Natürlich ist ein P4 auch x86-kompatibel, aber das ganze Konzept war ziemlich ineffizient, was das Verhältnis Taktrate/Leistung angeht und da sieht es eben generell bei der PPC-Architektur auch nicht besser aus. Es gibt schlichtweg keine PPC-Prozessoren, deren Taktraten/Leistungs-Verhältnis konkurrenzfähig wäre. D.h. die Prozessoren müssen recht aufwändig gekühlt werden. Das mag im High-End-Bereich keine so große Rolle spielen, ist aber insbesondere im Mobil-Bereich tödlich.

ROTFL - also noch frecher geht es nicht, mit dem Verdrehen der Wahrheit. SSE4 gibt es gerade mal seit kurzem, Altivec hingegen schon seit Jahren. Ausserdem ist Altivec AFAIK auch weiterentwickelt worden, mit Altive 2 bzw. wäre wohl ohne Switch gekommen.
Und? SSE gibt es ebenfalls seit Jahren, inzwischen hat es eben was Geschwindigkeit und Funktionsumfang betrifft an Altivec vorbeigezogen. Und komm' jetzt bitte nicht mit dem Märchen, dass der "böse, böse" Switch (Apple hat gerade einmal 2% des Kontingents verwendet), die Weiterentwicklung verhindert hätte.

Ich hatte mal einen Link zum Datenblatt bei IBM und da war wohl ein 2,7er AFAIF dabei. Bin mir aber nicht sicher. Und wie gesagt, darum geht es mir nicht!
Da täuscht Du Dich. Die letzten G5 wurden von Apple (kräftig) übertaktet.

Du kannst aber nicht abstreiten, dass der G5 im Vergleich zu Yonah alt ist. Ausserdem hat sich der G5 Quad ziemlich gut gegen Mac Pro behauptet, der viel neuer ist.

Siehe Ganons Posting...

Mit der PPC-Architektur hätte man mit Garantie auch viel bessere CPUs auf die Beine stellen können. Das es dazu nicht mehr kam, hängt an anderen Gründen, als an der eigentlichen Architektur -> um die es hier geht.

Spekulatius bzw. eine Aussage ohne Begründung. PPC hat keinesfalls nur von Apple gelebt bzw. haben sie es ja nicht einmal fertiggebracht, für Apple eine ordentliche Mobil-CPU auf die Beine zu stellen, was auch ein Grund für den Switch war, den man bei Apple sicherlich nicht leichtfertig entschieden hatte.

Ganon

2007-12-09, 16:32:18

Ganon, da bin ich nicht überall deiner Meinung. Aber das ist auch egal, da das nichts mit der Frage zur eigentlichen Architektur zu tun hat.

Was bringt es darüber zu diskutieren ob eine Architektur in der Theorie besser wäre, wenn es bisher nicht ein Mensch geschafft hat dies als Vorteil zu implementieren?

Und schon garnicht, mit der Frage des Threaderstellers!

Ob PPC oder x86 besser ist, hat mit dem Thread auch nichts zu tun, trotzdem diskutierst du darüber ;)

Gast

2007-12-09, 16:37:36

Die Aussage ist wahr, Du brauchst nur ein wenig Google zu bemühen oder genauer bei IBM zu recherchieren.
Spielt keine Rolle, da das mit der eigentlichen Architektur nichts zu tun hat.

Natürlich ist ein P4 auch x86-kompatibel, aber das ganze Konzept war ziemlich ineffizient, was das Verhältnis Taktrate/Leistung angeht und da sieht es eben generell bei der PPC-Architektur auch nicht besser aus.

Aha, und daraus schliesst du, dass man bei PPC keine effizienteren CPUs bauen kann? Danach hätte Intel nie einen Core2Duo entwickeln können, da P4 ja ineffizient! Natürlich wäre bei PPC mehr möglich.

Und? SSE gibt es ebenfalls seit Jahren, inzwischen hat es eben was Geschwindigkeit und Funktionsumfang betrifft an Altivec vorbeigezogen.
Altivec war vom Speed her lange SSE böse überlegen. Du bist derjenige, der ein Uralt-Altivec mit einem vor kurzem erschienen SSE4 vergleicht und davon ausgeht, dass bei PPC es in alle Ewigkeiten bei Altivec 1 geblieben wäre. Nett oder?

Und komm' jetzt bitte nicht mit dem Märchen, dass der "böse, böse" Switch (Apple hat gerade einmal 2% des Kontingents verwendet), die Weiterentwicklung verhindert hätte.
Ich bin nicht gegen x86. Habe selber einen und finde das Thema Virtualisierung interessant. Aber nach allem was ich gelesen habe, scheint mir PPC die überlegene Architektur zu sein.

Da täuscht Du Dich. Die letzten G5 wurden von Apple (kräftig) übertaktet.
Quad gibt es offiziell!

Spekulatius bzw. eine Aussage ohne Begründung. PPC hat keinesfalls nur von Apple gelebt bzw. haben sie es ja nicht einmal fertiggebracht, für Apple eine ordentliche Mobil-CPU auf die Beine zu stellen, was auch ein Grund für den Switch war.
Glaubst du ernsthaft, dass mit der PPC-Architektur weniger drin ist, als mit der aufgebohrten 70er Jahre-Architektur?

Lass mal bei PPC so Kohle fliessen inkl. Konkurrenzkampf wie bei x86 und da würde die Post abgehen.

In Anbetracht der Umstände halte ich x86 auch für richtig in den Macs - ändert aber nichts daran, dass PPC > x86 ist.

Gast

2007-12-09, 16:39:09

Ob PPC oder x86 besser ist, hat mit dem Thread auch nichts zu tun, trotzdem diskutierst du darüber ;)
Ok, und wie funktioniert jetzt die 32Bit-Kernel-Geschichte bei 10.5 mit x86?

mbee

2007-12-09, 16:44:11

Spielt keine Rolle, da das mit der eigentlichen Architektur nichts zu tun hat.

Aha, und daraus schliesst du, dass man bei PPC keine effizienteren CPUs bauen kann? Danach hätte Intel nie einen Core2Duo entwickeln können, da P4 ja ineffizient! Natürlich wäre bei PPC mehr möglich.

Warum gibt es die denn dann bittschön nicht, wie ich im letzten Posting schon erwähnt hatte, kannst Du das nicht alles argumentativ auf Apples Switch schieben.

Altivec war vom Speed her lange SSE böse überlegen. Du bist derjenige, der ein Uralt-Altivec mit einem vor kurzem erschienen SSE4 vergleicht und davon ausgeht, dass bei PPC es in alle Ewigkeiten bei Altivec 1 geblieben wäre. Nett oder?

Ich bin nicht gegen x86. Habe selber einen und finde das Thema Virtualisierung interessant. Aber nach allem was ich gelesen habe, scheint mir PPC die überlegene Architektur zu sein.

Yep, "war" ist das entscheidende Wort. Und nochmals, warum wurde hier nicht weiterentwickelt, sondern beim G5 sogar noch abgespeckt?

Quad gibt es offiziell!
Es ging um Deine Behauptung, Apple hätte die G5s bei den letzten Modellen nicht übertaktet, das ist falsch...

Glaubst du ernsthaft, dass mit der PPC-Architektur weniger drin ist, als mit der aufgebohrten 70er Jahre-Architektur?

Lass mal bei PPC so Kohle fliessen inkl. Konkurrenzkampf wie bei x86 und da würde die Post abgehen.

In Anbetracht der Umstände halte ich x86 auch für richtig in den Macs - ändert aber nichts daran, dass PPC > x86 ist.

Pure Polemik ohne Argumente und schon wieder das "hätte, wäre, könnte...".
Es geht hier um die Gegenwart und was aktuell nutzbar ist und Du versteigst Dich laufend in Spekulationen. Die Realität sieht eben nun mal anders aus.

Ganon

2007-12-09, 16:44:36

In Anbetracht der Umstände halte ich x86 auch für richtig in den Macs - ändert aber nichts daran, dass PPC > x86 ist.

Hätte, wenn, würde...

...ist es aber nicht. Punkt ;)

Ganon

2007-12-09, 16:45:30

Ok, und wie funktioniert jetzt die 32Bit-Kernel-Geschichte bei 10.5 mit x86?

kA? Guck in die Kernel-Sourcen.

Gast

2007-12-09, 16:56:27

Warum gibt es die denn dann bittschön nicht, wie ich im letzten Posting schon erwähnt hatte, kannst Du das nicht alles argumentativ auf Apples Switch schieben.
Wer braucht in Massen denn jetzt noch PPCs in Kosumerbereich, jetzt wo Apple weg ist? Selbst mit Apple wurden recht wenige PPCs nachgefragt im Vergleich zu x86. Klingelt es jetzt? Meinst du ohne Nachfrage und Konkurrenzkampf wird so entwickelt, wie bei Intel vs. Amd?

Yep, "war" ist das entscheidende Wort. Und nochmals, warum wurde hier nicht weiterentwickelt, sondern beim G5 sogar noch abgespeckt?
Es wurde/wird doch weiterentwickelt, bzw. Altivec 2 wäre sicherlich gekommen (@Ganon: In Xbox ist AFAIK wieder ein anderes Altivec).

Und PowerPC-Entwicklung geht schon weiter. Nur nicht im Desktop-Bereich, sondern im Embeded-Bereich (dort wo x86 bisher null Chance hat, warum wohl?) oder bei den ganz dicken Servern, von IBM und so.
Wobei der Pacifica interessant ist...

Es ging um Deine Behauptung, Apple hätte die G5s bei den letzten Modellen nicht übertaktet, das ist falsch...
Also ein Quad und ein 2,5 Dual wurde nicht übertaktet. 2,7 -> Quellen? Auch wenn ich es für möglich halte.

Pure Polemik ohne Argumente und schon wieder das "hätte, wäre, könnte...".
Es geht hier um die Gegenwart und was aktuell nutzbar ist und Du versteigst Dich laufend in Spekulationen. Die Realität sieht eben nun mal anders aus.
Redest du von dir. Mir geht es nur um die Architektur. Und da scheint ja PPC-Vorteile zu haben, bzw. ist morderner und besser. Das die Vorteile der Architektur nicht zum tragen kommen, liegt wie gesagt an mangelnder Verbreitung.
Aber um den Bogen zum Thema zu schlagen:

Wie funktioniert der 32Bit Kernel in 10.5 bei OSX. Wenn das wirklich ein Hack ist, dann ist das ja eigentlich nicht toll. Dann sind wir hier schon bei einem Punkt, wo der PPC seine Vorteile ausspielt - ohne Hacks.

Ganon

2007-12-09, 17:02:23

Dann sind wir hier schon bei einem Punkt, wo der PPC seine Vorteile ausspielt - ohne Hacks.

Dann such mal in den Kernel-Sourcen nach "Hack". Das meiste findest du im Bezug auf PPC ;)

Gast

2007-12-09, 17:02:56

Wie funktioniert der 32Bit Kernel in 10.5 bei OSX. Wenn das wirklich ein Hack ist, dann ist das ja eigentlich nicht toll. Dann sind wir hier schon bei einem Punkt, wo der PPC seine Vorteile ausspielt - ohne Hacks.
Oder andersrum: Wird eine CPU verwendet, die eigentlich nicht für die Anforderungen und Ideen von OSX und dem Mac geeignet ist und muss deswegen zu üblen Hacks gegriffen werden?

Dieses "64Bit-Spielchen" soll sich angeblich unter PPC noch weiter nutzen lassen, auch bei Plugins in Programmen. Keine Ahnung ob das stimmt.

Ganon

2007-12-09, 17:18:46

Oder andersrum: Wird eine CPU verwendet, die eigentlich nicht für die Anforderungen und Ideen von OSX und dem Mac geeignet ist und muss deswegen zu üblen Hacks gegriffen werden?

Nein, funktioniert doch alles bestens.

Gast

2007-12-09, 17:25:37

Nein, funktioniert doch alles bestens.
Ja, nur ist die Frage, warum es alles läuft?

Wenn es ein Hack sein sollte, der an der Spezifikation vorbei gewurchtelt wird, wirkt das nicht Vertrauen erregend. Kann aber wohl niemand beantworden...

Ich zitiere:

"Im i386-Kernel von Mac OS X sind aber ein paar ziemlich üble Hacks eingebaut, mit Ignorieren von Hardware-Exceptions, Auslesen von Registern, die in dem Mode lauft Doku gar nicht ausgelesen werden können etc., d.h. Ausnutzen von Bugs in der Implementation, die unter Intel irgendwie möglich machen, was unter PPC einfach so geht, weil es so vorgesehen ist: Es läuft ein 32bit-Kernel, obwohl der Prozessor eigentlich im 64bit-Modus läuft. 64 bit-Programme können im Userspace laufen, trotz 32-bit-Kernel."

"Die Kommentare in den Kernel-Sourcen sind sehr aufschlussreich. Den Kernel-Entwicklern bei Apple muss man auf jeden Fall Anerkennung zollen. Die haben das Beste aus der Fehlentscheidung ihres CEO gemacht. Die haben es irgendwie geschafft, den Kernel so laufen zu lassen, wie es eigentlich nur auf dem PPC möglich ist. Sogar die hierarchischen Device-Strukturen des PPC werden da nachgebaut (ein fakePPCDeviceTree).
Es ist übrigens kein 32/64bit-Mischbetrieb, es läuft bei eingeschaltetem Long-Mode ein 32bit-Kernel im Compatibility-Mode.

Die Bugs in der Implementation, die Apple hier ausnutzt, um den Kernel in den für User-Prozesse reservierten Compatibility-Mode zu schieben, scheinen ja übergreifend vorhanden zu sein. Mac OS X läuft ja nicht nur auf Intel, sondern auch auf AMD-CPUs.

Einerseits denke ich, dass diese Bugs in der Implementation irgendwann ausgeräumt werden müssen. Das ist sicherlich auch eine potenzielle Sicherheitslücke, wenn man Kernel-Code im schlechter gesicherten Compatibility-Mode ausführen kann. Auf Apple wird Intel da jedenfalls kein Rücksicht nehmen. Andererseits denke ich, dass die dass diese Bugs in der Implementation nicht ausgeräumt werden. Bislang hat Intel noch jeden Fehler in der ISA über Generationen mitgeschleppt.

Apple wird sicherlich in der nächsten (oder einer der nächsten) Version von Mac OS X auf einen 64 bit Kernel umschwenken. Das hat zwar zur Folge, dass der Kunde mal wieder alle seine vorhandene Hardware einstampfen kann, da es dafür dann keine Treiber gibt. Aber da hat sich Apple bekanntlich noch nie drum geschert."

"Nee, so kann man das nicht sagen. Eher könnte man sagen: Der Kernel läuft in einem Modus, den es eigentlich gar nicht geben darf.
Er läuft im Kernel-Modus des Compatibility-Modus. Den gibt es, weil der Compatibility-Modus identisch mit dem 32-bit-Modus innerhalb des Legacy-Modus ist (auf gut deutsch ein x86 ohne die 16bit-Segment-Adressierung). Der Zugang dazu ist aber eigentlich durch eine Hardware Exception gesperrt. Apple schafft es aber trotzdem Code in diesem Modus auszuführen.

Außerdem, das ist nichts neues. Das gibt es so seit Einführung des ersten Intel-"Macs" mit 64bit-Erweiterung (MacPro, August 2006). Die Sourcen, die von denen ich rede, sind die vom 10.4-Kernel, im 10.5-Kerle hat sich aber eh nichts geändert."

"Dass da intern Saltos gemacht werden müssen, da hast Du allerdings recht. Wenn Du mal Zeit hast, lad Dir einfach mal die Kernel-Sourcen bei Apple und lies Dir die Kommentare darin durch. Das ist sehr interessant."

"Nee, so kann man das nicht sagen. Eher könnte man sagen: Der Kernel läuft in einem Modus, den es eigentlich gar nicht geben darf.
Er läuft im Kernel-Modus des Compatibility-Modus. Den gibt es, weil der Compatibility-Modus identisch mit dem 32-bit-Modus innerhalb des Legacy-Modus ist (auf gut deutsch ein x86 ohne die 16bit-Segment-Adressierung). Der Zugang dazu ist aber eigentlich durch eine Hardware Exception gesperrt. Apple schafft es aber trotzdem Code in diesem Modus auszuführen."

"Falls Du gerade vom x86-64 sprichst, der kann sowieso keine Terabytes flach adressieren. Da stehen als Adressleitungen nur 40bit zur Verfügung und das Speichermanagement ist die 48-bit-Version von PAE (in einer späteren Revision sind dann 52 bit geplant, dann 56, 60 und irgendwann mal 64 bit).

Falls Du vom PPC sprichst, da werden solche Sprünge eh nicht gemacht."

Gast

2007-12-09, 17:30:48

"Jedenfalls ist es beim Intel nicht möglich, wenn man sich an die, sicherlich nicht ohne Grund gemachten, Vorgaben von Intel bzw. AMD hält. 64 bit ist nur möglich, wenn der Kernel und alle Erweiterungen 64 bit sind. So stehts ausdrücklich in der Intel- und in der AMD Dokumentation.

In der PPC-Doku dagegen wird der 64-bit-Betrieb mit 32-bit-Kernel, wie Mac OS X den macht, ausdrücklich erwähnt. Der Kernel kann, obwohl 32 bit, im 64-bit-Modus laufen. Es ist umgekehrt auch möglich, 64-bit-Befehle im 32-bit-Modus auszuführen. Es wird sogar darauf hingewiesen, dass selbst einzelne 64-bit-Befehle in 32-bit-Code eingefügt werden können."

Ganon

2007-12-09, 17:31:05

Gast

2007-12-09, 17:35:49

Sry, aber Beweise, Links, Datei/Zeile, bitte nicht von den gestörten PPCNUX-Leuten?

Ich kann in den Leopard-Kernel-Sourcen nichts dergleichen finden...

Und das Tiger ein ziemlich fixer x86-Hack war, habe ich ja bereits gesagt, entsprechend war auch die Performance der x86er unter Tiger...
Frage die Leute bei PPCNUX: http://www.ppcnux.de/?q=node/7105

Alleine schon die Aussage "Im Leopard-Kernel habe sich nichts geändert" ist ziemlicher Schwachsinn...
Da stimme ich dir allerdings zu!

Sollten die Aussagen stimmen, dann hat aber PPC riesen Vorteile gegenüber x86, was den ganzen Wechsel zu 64Bit betrifft, wenn man die PPC-Möglichkeiten nutzt. Da man das bei x86 nicht kann, gibt es solche Threads: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=394577

Ich will nicht trollen, mich interessiert das aber einfach und habe selber zuwenig Ahnung, um wirklich mitreden zu können. Problem ist, dass ich den Leuten bei PPCNUX auch nicht blind glaube. Und hier bei 3dcenter sich niemand ausserhalb von x86 wirklich auskennt.

Ganon

2007-12-09, 17:40:12

Frage die Leute bei PPCNUX: http://www.ppcnux.de/?q=node/7105

Meinst du das habe ich damals nicht getan? Sry, aber von denen kommt eben nur Schwachsinn (720p H.264@G4 500Mhz :ugly:). Und "Oh Gott", wenn ich auf den Link klick und die Schwachsinnskommentare zu Carbon lese... das tut weh.....

Sollten die Aussagen stimmen, dann hat aber PPC riesen Vorteile gegenüber x86, was den ganzen Wechsel zu 64Bit betrifft, wenn man die PPC-Möglichkeiten nutzt. Da man das bei x86 nicht kann, gibt es solche Threads: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=394577

Was haben Windows64-Probleme mit OS X zu tun?

Ich will nicht trollen, mich interessiert das aber einfach und habe selber zuwenig Ahnung, um wirklich mitreden zu können.

Und warum tust du es denn hier aktiv? Stellst Sachen in den Raum ohne Beweise?

Problem ist, dass ich den Leuten bei PPCNUX auch nicht blind glaube. Und hier bei 3dcenter sich niemand ausserhalb von x86 wirklich auskennt.

Benutze die Suchfunktion. Das Thema hatten wir hier schon oft genug, deswegen schreibt hier auch keiner mehr etwas dazu...

Gast

2007-12-09, 17:44:25

Meinst du das habe ich damals nicht getan? Sry, aber von denen kommt eben nur Schwachsinn (720p H.264@G4 500Mhz :ugly:).
Woher soll ich das wissen? Ausserdem wer sagt, dass die nur Schwachsinn von sich geben?

Was haben Windows-Probleme mit OS X zu tun?
Wei Windows an die Einschränkungen der x86-Architektur gebunden ist, sofern der PPCNUX-Kram stimmt?

Und warum tuest du es denn hier aktiv?
Ich habe einfach die Fragestellung des Threadstarters aufgegeriffen. Ist kein Trollen. Ignorieren gewisser Dinge, die evtl. stimmen, ist eher trollen! ;)

Stellst Sachen in den Raum ohne Beweise?
Ich denke du und andere sind eher dran zu beweisen, dass x86 bei PPC mithalten kann, denn offenbar gibt es laut AMD und Intel-Spezifikation keinen Modus, indem ein 32Bit-Kernel so wie bei Leopard laufen kann! Also!

Benutze die Suchfunktion. Das Thema hatten wir hier schon oft genug, deswegen schreibt hier auch keiner mehr etwas dazu...
Woher soll ich das wissen. Habe zu der Frage des Threaderstellers keine Antwort gefunden und kann offenbar auch niemand beantworten? Daher die Annahme, dass die PPCNUX-Jungs doch Recht haben?

Gast

2007-12-09, 17:48:48

@Ganon: Nochetwas!

Beim Bios willst du keine Hacks aber bei so etwas essentiellem wie einem Kernel, nimmst du evtl. Hacks (sofern die Aussagen stimmen sollten) hin?

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=5830241&highlight=EFI#post5830241

Ganon

2007-12-09, 17:53:16

Woher soll ich das wissen? Ausserdem wer sagt, dass die nur Schwachsinn von sich geben?

Meine Erfahrung-

Wei Windows an die Einschränkungen der x86-Architektur gebunden ist, sofern der PPCNUX-Kram stimmt?

Ah ja... klar... Weil es unter Windows nicht geht, darf es unter OS X auch nicht gehen... soso... Keks?

Ich habe einfach die Fragestellung des Threadstarters aufgegeriffen. Ist kein Trollen. Ignorieren gewisser Dinge, die evtl. stimmen, ist eher trollen! ;)

Verbreiten von Kommentare von Deppen, ist trollen... ich habe damals nachgefragt und nie eine Antwort von ihnen bekommen, von daher gehe ich davon aus, das es keine gibt...

Ich denke du und andere sind eher dran zu beweisen, dass x86 bei PPC mithalten kann, denn offenbar gibt es laut AMD und Intel-Spezifikation keinen Modus, indem ein 32Bit-Kernel so wie bei Leopard laufen kann! Also!

Der Kernel läuft aber in diesem Modus und alles läuft auch ziemlich problemlos... nur weil den PPC-Fanatikern die Argumente ausgehen, muss es nicht auch gleich alles ein "übler Hack" sein. Und ich hab auch kein Bock mich über irgend ein theoretischen Blödsinn zu unterhalten. Die Praxis sagt mir was anderes und wenn es jemand widerlegen will, dann will ich Beweise. Und nein, ich werde nicht aktiv um den Schwachsinn von anderen zu widerlegen, wenn es nicht mal Beweise der Gegenseite gibt...

Woher soll ich das wissen.

Dann informiere dich...

Ganon

2007-12-09, 17:56:12

Beim Bios willst du keine Hacks aber bei so etwas essentiellem wie einem Kernel, nimmst du evtl. Hacks (sofern die Aussagen stimmen sollten) hin?

Hast du zufällig Langeweile?

Was hat denn das eine mit dem anderen zu tun? Ein "übler Hack" (wie z.B. das BIOS) ist etwas was nur halb oder gar nicht funktioniert. Das trifft auf den Kernel von OS X aber nicht zu, denn der läuft bestens...

Gast

2007-12-09, 17:59:01

Der Kernel läuft aber in diesem Modus und alles läuft auch ziemlich problemlos... nur weil den PPC-Fanatikern die Argumente ausgehen, muss es nicht auch gleich alles ein "übler Hack" sein. Und ich hab auch kein Bock mich über irgend ein theoretischen Blödsinn zu unterhalten. Die Praxis sagt mir was anderes und wenn es jemand widerlegen will, dann will ich Beweise. Und nein, ich werde nicht aktiv um den Schwachsinn von anderen zu widerlegen, wenn es nicht mal Beweise der Gegenseite gibt...

Als Beweis sollte erstmal ausreichen, dass es diesen Modus nirgends in der Doku von AMD und Intel gibt. Dann wäre eher fällig, warm es anscheinend trotzdem geht?

Weil es die PPCNUX-Jungs sagen, muss es natürlich Schwachsinn sein? Das geht mir auf den Zeiger. Mag ja sein, dass die viel Müll von sich geben aber hier sieht es momentan nicht danach aus. Auch Leute wie Legolas werden stutzig! Ü

Übrigens: Bios läuft auch trotz Hacks. Warum dann so gegen Bios und für Efi, wenn das Bios eh mehr verbreitet ist? ;) *stichel*

Falls die Behauptungen von PPCNUX stimmen, wäre das glaube schon ein Bug, weil afaik von 32bit Code, der im Compatibility Mode des 64bit Modus läuft, keine privilegierten Instruktionen ausgeführt werden können. Ohne diese, kann man aber kein OS wie Mac OS X bauen.
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=6018955#post6018955

Gast

2007-12-09, 18:01:51

Hast du zufällig Langeweile?

Was hat denn das eine mit dem anderen zu tun? Ein "übler Hack" (wie z.B. das BIOS) ist etwas was nur halb oder gar nicht funktioniert. Das trifft auf den Kernel von OS X aber nicht zu, denn der läuft bestens...

Moment - wenn die PPCNUX-Jungs recht haben, läuft hier bei Intel OSX ein Hack^1000 ab, gegen den Bios-Hacks absolut harmlos sind.

Darum geht es doch! AMD und INTEL Doku auf der einen Seite - OSX 32Bit Kernel bei 10.5 auf der anderen Seite.

Ganon

2007-12-09, 18:05:40

*stichel*

OK, damit hast du bewiesen das du keiner sinnvollen Diskussion fähig bist und nur trollen willst.

Kein Bock meine Zeit damit zu verschwenden... finde deine Informationen alleine oder sterbe dumm...

Bin offen für Beweise aller hier aufgestellten Behauptungen, wenn diese nicht kommen und nur PPCNUX-Blafasel kommt, schreibe ich nichts mehr....

Gast

2007-12-09, 18:10:33

OK, damit hast du bewiesen das du keiner sinnvollen Diskussion fähig bist und nur trollen willst.

Kein Bock meine Zeit damit zu verschwenden... finde deine Informationen alleine oder sterbe dumm...

Bin offen für Beweise aller hier aufgestellten Behauptungen, wenn diese nicht kommen und nur PPCNUX-Blafasel kommt, schreibe ich nichts mehr....

Also was soll das Verhalten und der Ton? Wie ein trtoziges Kind! Spricht nicht für dich.

Du kommst nicht mehr weiter und dann das...

... du weisst keine Antwort. Deswegen musst du den Ton nicht an den Tag legen.

Fakt: In der Dokumentation gibt es nicht diesen Modus, in dem der Kernel von Mac OS 10.5 läuft. Was soll man dann noch an Beweisen bringen?
Wie kann der dann trotzdem laufen!

Gast

2007-12-09, 18:19:17

Fakt: In der Dokumentation gibt es nicht diesen Modus, in dem der Kernel von Mac OS 10.5 läuft. Was soll man dann noch an Beweisen bringen?
Wie kann der dann trotzdem laufen!
Oder gibt es nichts in der Dokumentation, da weder Intel, noch AMD auf die Idee kamen, einen Kernel so wie bei 10.5 laufen zu lassen?

Demogod

2007-12-09, 18:37:06

Apple versucht vermutlich einfach die 32>64 Bit migration möglichst smooth ablaufen zu lassen.
Ich mein : Hey, der 68k war schon ein 32 bit proz und die produktlinie von (big bro) IBM war eigentlich auch schon immer 64Bit.

Der ganze Hickhack , OMG!.
Ich wette Apple (his godness steve) hat das nie so geplant.

Apple versucht wirklich dem Endverbraucher ein gutes Produkt an die Hand zu liefern, und hätte IBM es mal geschafft, mehr "techs" zu günstigen Preisen zu liefern, müsste Apple ALL diese Wege nicht gehen.

Gast

2007-12-09, 18:49:40

Apple versucht vermutlich einfach die 32>64 Bit migration möglichst smooth ablaufen zu lassen.
Natürlich versucht das Apple und das ist auch gut. Nur was da Apple gemacht hat, geht wohl problemlos mit PowerPC, da es dort wohl vorgesehen ist. Bei x86 laut Doku aber wohl nicht bzw. dürfte eigentlich gar nicht funktionieren. Ich habe selber versucht zu suchen und konnte nichts finden. Jetzt ist die Frage, warum und wie es bei x86 geht? Übler Hack an Spezifikationen vorbei oder doch ohne "Murks" irgendwie möglich?

Ganon

2007-12-09, 20:29:22

OK. Hab ich mich jetzt doch dazu "durchgerungen" mir die ganze Sache mal anzugucken...

Also in den Kernel-Sourcen findet man in den Dateien:

$srcDir/osfmk/i386/start64.s
$srcDir/osfmk/i386/idt64.s

Eine schöne Abhandlung was passiert, beim Start.

Erst schaltet er die CPU in den 64bit-Modus, richtet den Speicher ein, schaltet dann in den Compatibility-Modus und lädt dann den Kernel.

Ich lese da in den Kommentaren da weder etwas von Hacks, noch sonst etwas.

Auch in den x86_64 Dokumenten von AMD konnte ich nichts dazu finden, dass dieses Vorgehen nicht funktionieren würde, oder falsch wäre.

So, jetzt zufrieden?

Jetzt klinke ich mich aber wirklich aus. Für alles andere Links, Beweise, Seitenzahlen, Absätze, usw. usw. Kein Bock mehr zu suchen...

Gast

2007-12-09, 21:46:43

Also wenn man nach "start64.s" und "idt64.s" googelt, findet man threads, in denen wir nicht allein sind, in denen man rätselt (auch im parallels-forum - allerdings liegt das schon einige monate zurück).

habe das hier gefunden:

195 /* FXSAVE and FXRSTOR operate in a mode dependent fashion, hence these variants.
196 * Must be called with interrupts disabled.
197 * We clear pending x87 exceptions here; this is technically incorrect, since we
198 * should propagate those to the user, but the compatibility mode kernel is
199 * currently not prepared to handle exceptions originating in 64-bit kernel mode.
200 * However, it may be possible to work around this should it prove necessary.
201 */
202
http://fxr.watson.org/fxr/source/osfmk/i386/start64.s?v=xnu-1228

Gast

2007-12-09, 22:05:53

Weiss nicht ob es weiterhilft... http://fxr.watson.org/fxr/source/osfmk/i386/idt64.s?v=xnu-1228

Gast

2007-12-09, 22:51:36

The second mode supported by the AMD64 and EM64T is compatibility mode, which is an intermediate mode of the full 64-bit mode described below. In order to run in compatibility mode, you will need to install a 64-bit operating system and 64-bit drivers. If a 64-bit OS and drivers are installed, both Opteron and Xeon processors will be enabled to support a 64-bit operating system with both 32-bit applications or 64-bit applications.
http://www.redbooks.ibm.com/abstracts/tips0475.html

This means that the AMD64 Linux kernel cannot use x86 drivers unless the drivers are recompiled to the AMD64 architecture. This paper provides code samples and instruction on porting x86 device drivers to AMD64 on Linux.
http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_11395_11428,00.html

If a 32-bit operating system is installed, the processor will run in 32-bit mode. In this case 64-bit drivers are not required.

With a 64-bit operating system the computer will either operate in 64-bit mode or what is called Compatibility Mode. In either mode all system drivers must be 64-bit. In 64-bit mode 64-bit and 32-bit applications can be running in the system concurrently. Legacy 32-bit applications run in Compatibility Mode. 64-bit applications will have new executables not compatible with 32-bit apps. In other words 64-bit applications generally cannot share libraries with 32-bit executables.

http://img103.imageshack.us/img103/822/bild1px2.png
http://www.intel.com/cd/channel/reseller/asmo-na/eng/203142.htm

Und x86-32bit-Kernel inklusiv x86-32bit-Kernel-Space-Treibern in Compatibility-Mode?

Gast

2007-12-09, 22:55:30

Eine schöne Abhandlung was passiert, beim Start.

Erst schaltet er die CPU in den 64bit-Modus, richtet den Speicher ein, schaltet dann in den Compatibility-Modus und lädt dann den Kernel.

!=

In order to run in compatibility mode, you will need to install a 64-bit operating system and 64-bit drivers.
http://www.redbooks.ibm.com/abstracts/tips0475.html

:???:

Ganon

2007-12-09, 22:58:49

Das Zitat von IBM ist Marketing (bzw. Reseller-Infos), das von AMD bezieht sich auf Linux und das von Intel ist auch (wie das von IBM und AMD) keine Spezifikation, sondern eher ein Hinweis für Reseller, welche ja normalerweise Windows/Linux installieren.

In den x86_64 Spezifikationen lese ich nichts davon. Wenn ich es überlesen habe, bitte sagen wo...

Gast

2007-12-09, 23:21:28

Hmmm...
Wikipedia schreibt:

Software availability
64-bit systems sometimes lack equivalents to software that is written for 32-bit architectures. The most severe problem is incompatible device drivers. Although most software can run in a 32-bit compatibility mode (also known as an emulation mode, e.g. Microsoft WoW64 Technology), it is usually impossible to run a driver (or similar software) in that mode since such a program usually runs in between the OS and the hardware, where direct emulation cannot be employed. Many open source software packages can simply be compiled from source to work in a 64-bit environment on operating systems such as Linux. All that would be needed in this case is a compiler (usually gcc) for the 64-bit machine. Currently the 64-bit versions for most device drivers are not available, so using a 64-bit operating system can become frustrating due to a lack of available drivers.
Because device drivers in operating systems with monolithic kernels, and in many operating systems with hybrid kernels, execute within the operating system kernel, it is possible to run the kernel as a 32-bit process while still supporting 64-bit user processes. This provides the memory and performance benefits of 64-bit for users without breaking binary compatibility with existing 32-bit device drivers, at the cost of some additional overhead within the kernel. [b[This is the mechanism by which Mac OS X enables 64-bit processes while still supporting 32-bit device drivers.[/b]

http://en.wikipedia.org/wiki/64-bit

Zu OSX das hier gefunden:

"Bei Mac OS X werden die Treiber zwar auf der Festplatte als einzelne Kext-Dateien gespeichert, im Speicher werden jedoch Kernel und Treiber in einen gemeinsamen Speicherbereich geladen und zu einem einzigen Prozess zusammengefasst (um die Kommunikation zu beschleunigen). Im ungeladenen Zustand hat Mac OS X einen Microkernel und Kernel-Extensions, im geladenen Zusatnd einen monolithischen Kernel. 32bit-Code innerhalb eines 64bit-Prozesses ist bei x86 gar nicht und beim PPC nur mit kleinen Tricks möglich."

Ganon

2007-12-09, 23:33:53

Entweder du zitierst mir jetzt etwas aus den x86_64 Spezifikationen oder gar nichts...

Alles andere hat keinen Sinn.

Gast

2007-12-09, 23:42:43

Entweder du zitierst mir jetzt etwas aus den x86_64 Spezifikationen oder gar nichts...

Kann momentan nur das hier finden:

http://ein.designreactor.com:8080/amd_devCentral/content/images/article_images/5932.gif
http://ein.designreactor.com:8080/amd_devCentral/articlex.jsp?id=73

Bei ArsTechnica wurde die Frage auch im Forum gestellt:

If someone could enlighten me how an 64Bit OS with 64Bit API is running on 32 bit kernel?
In x86-64, the mode of any piece of code (32-bit compatibility mode or 64-bit long mode) is set by a bit in the cs register. The system call instructions allow a value for the cs register to be specified, which is loaded into the register when the system call is invoked. If the long mode bit is cleared in that value of 'cs', then when 64-bit code invokes a system call, the processor will switch back into 32-bit mode. When the system call returns, the processor will switch back into 64-bit mode.

In addition to the mode switch, the 64-bit libc (C library) has to cooperate to allow usage of a 32-bit kernel. For example, if it stores a 64-bit value in a register, when the mode switch occurs, the kernel will only see the lower 32-bits of that value. So the C library has to take this truncation into account.

Things aren't quite as difficult as they may seem at first. Remember that the kernel can't directly use pointers passed in from userspace anyway. It's a major security risk on any kernel , and in Darwin it's not even technically possible, because the kernel lives in a separate address space. So in the kernel there are APIs for copying data to and from userspace. These APIs work by temporarily mapping bits of the process's address space into the kernel. If these APIs are updated to account for 32-bit user processes, the kernel itself doesn't need to handle 64-bit pointers (directly).

PS) If this sounds messy, well, it is. But this is Darwin. You're already in the sticks, so you might as well enjoy the grits!
http://episteme.arstechnica.com/eve/forums/a/tpc/f/174096756/m/585002628831/p/4

Ganon

2007-12-09, 23:49:14

Das sagt jetzt auch nur das es geht und kein "Ausnutzen eines x86_64-Bugs" ist, oder sonst irgendetwas "schlimmes". Außerdem erklärt der Arstechnica-Beitrag nur wie es über dem Kernel abläuft.

Von daher können wir das Thema abhaken, oder?

Coda

2007-12-10, 00:01:42

Der Microkernel läuft im 64-Bit-Modus, die Clients (also der restliche Kernel) teilweise nur im 32-Bit-Modus. Überhaupt kein Problem, weil diese keinen priviledged Code enthalten. Es ist überhaupt nicht möglich einen Prozessor in den Long-Mode zu versetzen ohne wenigstens die grundsätzlichen Kernelsysteme auch in x86-64 zu schreiben.

Ganz einfach. Es gibt überhaupt keine "ausgenützten Bugs".

Gast

2007-12-10, 00:07:36

Danke für den Post, nur steht überall, dass 10.5 einen 32Bit Kernel hat, u.a. auch bei ArsTechnica: "Apple has gone 64-bit across the board, with two major exceptions. The first is the kernel itself, which remains 32-bit in order to maintain compatibility with existing drivers."
http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/6

@Leute mit Leopard und 64Bit Cpu: Bitte mal nachschauen, was die Konsole so ausspuckt!

Ganon

2007-12-10, 08:54:13

Was hast du an den Ausführungen von Coda nicht verstanden?

Gast

2007-12-10, 10:50:02

Ich glaube ich habe die Ausführungen verstanden und so hatte ich auch gedacht, dass es funktioniert. Dann ist ein (kleiner) Teil des Kernels aber in 64Bit oder? Aber angeblich ist der Kernel in Leopard ja vollständig in 32Bit und sowohl 64Bit und 32Bit Macs nutzen den gleichen Kernel.

Oder ist letztere Aussage einfach falsch bzw. man macht aus einem Kernel, der in Großteilen 32Bit ist (aber nicht vollständig) einfach im Wortlaut einen reinen 32Bit Kernel?

Coda

2007-12-10, 21:48:41

Vollständig in 32-Bit kann gar nicht sein, weil die Page-Fault-Exception-Handler usw. bei x86-64 auf jeden Fall in 64-Bit-Code sein müssen.

Lokadamus

2007-12-10, 22:02:02

... Dann ist ein (kleiner) Teil des Kernels aber in 64Bit oder?mmm...

Der Text in Wikipedia deckt sich so gesehen mit Codas Aussage:
Ein Mikrokernel (oder auch Mikrokern) bezeichnet einen Betriebssystemkern. Der Mikrokernel verfügt über weniger Funktionen als ein Monolithischer Kernel – in der Regel lediglich Funktionen zur Speicher- und Prozessverwaltung, sowie Grundfunktionen zur Synchronisation und Kommunikation.
http://de.wikipedia.org/wiki/Mikrokernel

Das deckt sich meiner Meinung nach ebenso mit der Veranschaulichung von Appel:
http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/additionalfeatures/chapter_10_section_8.html

Es wird dabei nicht darauf eingegangen, ob es 64 oder 32 Bit sind, aber in Zusammenhang mit Ganons Aussage ala "es wird zuerst im 64Bit- Modus gestartet und der Rest danach als 32Bit- Anwendung" würde gut dazu passen.

beos

2007-12-10, 22:53:56

Ändert nichts an der Tatsache, dass PPC besser als x86 ist!

Ich glaub es ist auch nicht schwierig bei einer 13 Jahren später eingeführten Architektur etwas besser zu machen ;)

Gast

2007-12-10, 23:18:42

Vollständig in 32-Bit kann gar nicht sein, weil die Page-Fault-Exception-Handler usw. bei x86-64 auf jeden Fall in 64-Bit-Code sein müssen.

So wird es wohl auch sein müssen! In div. Foren ist auch ab und an die Rede von Aussagen wie "99 Prozent des Kernels ist in 32Bit." Also nicht vollständig, wie sonst immer behauptet. Blöd, dass die Kernelgeschichte anscheinend nirgends wirklich beschrieben ist. Aber die "Buggeschichte" halte ich eigentlich auch für weit hergeholt. Bin halt sehr skeptisch geworden.

Wenn ein Macbook Core2Duo Besitzer mal ein "uname -a" macht?

Evil E-Lex

2007-12-10, 23:33:18

Wenn ein Macbook Core2Duo Besitzer mal ein "uname -a" macht?

Ist zwar von einem iMac mit Core2Duo, aber der Kernel ist der gleiche:
Darwin imac.evil.lan 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386

Gast

2007-12-11, 16:33:05

Ist zwar von einem iMac mit Core2Duo, aber der Kernel ist der gleiche:
Darwin imac.evil.lan 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386

Danach also ein reiner 32Bit Kernel?

Ganon

2007-12-11, 16:35:51

Demnach gibt der Kernel als Architektur-Typ i386 aus ;)

Gast

2007-12-11, 16:55:21

Demnach gibt der Kernel als Architektur-Typ i386 aus ;)
Stehe jetzt auf dem Schlauch :D

Ganon

2007-12-11, 17:03:50

uname -a gibt bloß den Text zurück den der Kernel liefert. Wenn man will kann da auch Pilzsuppe stehen.

Nur weil da i386 steht, heißt das nicht das intern 64bit-Funktionen laufen. Diese müssen einfach laufen, sonst würden auch keine 64bit-Prozesse laufen können.

edit:
Du kannst doch an den Code-Stücken aus den beiden Assembler-Dateien dort sehen, das 64bit-Code abläuft, also weiß ich nicht wo dein Problem jetzt noch ist.

Gast

2007-12-20, 13:50:20

mmm...

Der Text in Wikipedia deckt sich so gesehen mit Codas Aussage:
Ein Mikrokernel (oder auch Mikrokern) bezeichnet einen Betriebssystemkern. Der Mikrokernel verfügt über weniger Funktionen als ein Monolithischer Kernel – in der Regel lediglich Funktionen zur Speicher- und Prozessverwaltung, sowie Grundfunktionen zur Synchronisation und Kommunikation.
http://de.wikipedia.org/wiki/Mikrokernel
der kernel von mac os x ist aber gar kein mikrokernel nach dieser definition. der mikrokernel wird beim laden mit den treibern zu einem monolithen verschmölzen.

[/QUOTE]Das deckt sich meiner Meinung nach ebenso mit der Veranschaulichung von Appel:
http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/additionalfeatures/chapter_10_section_8.html

Es wird dabei nicht darauf eingegangen, ob es 64 oder 32 Bit sind, aber in Zusammenhang mit Ganons Aussage ala "es wird zuerst im 64Bit- Modus gestartet und der Rest danach als 32Bit- Anwendung" würde gut dazu passen.[/QUOTE]
bei mac os x laufen aber der mikrokernel und die treiber zusammen in einem prozess. wie bei einem monolithischer kernel.
in einem prozess kann 32 und 64 bit code nicht gemischt werden. beim x86 gar nicht und beim powerpc je nach binärformat zum teil nur mit eingefügten assembler code.

Ganon

2007-12-20, 13:57:42

Guck dir einfach den Source-Code an und gut ist. Der wurde weiter oben schon gepostet...

Gast

2007-12-20, 14:38:08

bei mac os x laufen aber der mikrokernel und die treiber zusammen in einem prozess. wie bei einem monolithischer kernel.
in einem prozess kann 32 und 64 bit code nicht gemischt werden. beim x86 gar nicht und beim powerpc je nach binärformat zum teil nur mit eingefügten assembler code.

"Q: So now I'm wondering, can 64-bit unix kernel calls be mixed freely within a 32-bit Carbon GUI environment?

No, the Mac OS programming model does not support mixing 32-bit and 64-bit calls in the same process (regardless of whether you're using Carbon, Cocoa, or just BSD Unix calls).

-eric
http://www.carbondev.com/site/?page=64-bit+Carbon

Gast

2007-12-20, 17:36:58

"Q: So now I'm wondering, can 64-bit unix kernel calls be mixed freely within a 32-bit Carbon GUI environment?

No, the Mac OS programming model does not support mixing 32-bit and 64-bit calls in the same process (regardless of whether you're using Carbon, Cocoa, or just BSD Unix calls).

-eric
http://www.carbondev.com/site/?page=64-bit+Carbon

"Code using the 32-bit PowerPC ABI can execute assembly instruction functions in 64-bit computation mode. The assembly language function can switch to the 64-bit computation mode. execute a series of instructions and then switch back to 32-bit computation mode.

[...]

For example, if 32-bit software is performing 64-bit scalar arithmetic operations the arithmetic operations can be written in assembly language. Such assembly function can be called from high level languages."

"The kernel can be either 32- or 64-bit oriented.

[...]

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."

http://www.ibm.com/chips/techlib/techlib.nsf/techdocs/AB70A3470F9CC0E287256ECC006D6A54/$file/970-software.pdf

ste^2

2007-12-29, 00:45:09

Coda

2007-12-29, 01:14:23

Genau so wie ich es mir gedacht habe...

Von wegen PowerPC ist dort überlegen. Es ist exakt das gleiche Design.

Gast

2007-12-29, 03:01:49

Senior Sanchez

2007-12-29, 03:37:58

von powerpc steht dort aber glaube ich nichts oder?
kann man das mal grob erklären, wie das jetzt beim mac mit den 64bit funktioniert?

"The OS X kernel is not 64 bit. It supports 64
bit user mode applications on a 64 bit PowerPC
or Intel CPU, but the kernel itself runs
in 32 bit mode and is bound to the 4 GB address
space limit."

hört sich ja ziemlich interessant an.

Also ich hab es so verstanden...

Der Kernel (XNU) läuft in 32-Bit Mode. Jede Applikation wird scheinbar getestet und wenn diese in 64-Bit Modus laufen will, so wird in den Long-Mode gewechselt, sodass 64-Bit adressiert werden könnten. Nachteilig ist allerdings, dass die 64-Bit Register nicht genutzt werden können.

Was ich außerdem daran nicht so ganz verstehe: das Memory Management wird ja durch Mach bereit gestellt. Aber wenn der Kernel nur in 32 Bit läuft - wie kann dann eine Applikation 64 Bit Adressen zum adressieren von Speicher nutzen?

Ganon

2007-12-29, 11:16:18

Och Leute, steht doch alles da... wenn eine 64bit CPU genutzt wird, startet der Kernel im Long-Mode, sodass er 32bit und 64bit unterstützt. Der Kernel selbst läuft im 32bit-Modus und wenn eine 64bit-Anwendung kommt, schaltet er in den 64bit-Modus und lässt laufen.

Der Nachteil an der Sache ist nur, dass der >Kernel< halt nur 4GB RAM adressieren und die zusätzlichen Register nicht nutzen kann. Für die 64bit-Anwendungen gilt das natürlich nicht.

So, das hatten wir jetzt wie oft im Thread? 10mal? Und in dem Artikel steht auch nichts von PowerPC, WEIL ES BEI POWERPC GENAUSO IST!!!

Senior Sanchez

2007-12-29, 21:04:51

Gast

2007-12-29, 23:30:44

Warum liest du nicht den PDF?

ste^2

2008-01-02, 14:55:45

Das hier habe ich vorhin gefunden aber selber noch nicht gelesen!

24th Chaos Communication Congress
Volldampf voraus!

Inside the Mac OS X Kernel (http://events.ccc.de/congress/2007/Fahrplan/attachments/986_inside_the_mac_osx_kernel.pdf)
Debunking Mac OS Myths

http://events.ccc.de/congress/2007/Fahrplan/events/2303.en.html

Edit: Super Artikel!!! Absolut lesenswert!

Hier gibt es den Vortrag als Video:

http://ftp.uni-kl.de/24C3/mp4/24c3-2303-en-inside_the_macosx_kernel-COMPATIBLE.mp4

Wer wie ich den Singh im Regal stehen hat, aber noch innerhalb der ersten 100 Seiten aufgegeben hat (verdammt, eigentlich bin ich Informatiker!!), erhält von ihr eine sehr gut strukturierte, nicht zu tiefe Einführung in die Feinheiten des OS X Kernels.
http://www.fscklog.com/2008/01/sammelsurium-op.html#comments

Edit:
Es geht auch kurz über Bios vs. EFI.

Schnuller4u

2008-01-02, 23:28:18

Warum liest du nicht den PDF?
Na, ist das wirklich alles so klar (http://www.ppcnux.de/?q=node/7171#comment-12633)?

Ganon

2008-01-02, 23:38:11

Ab

"Allerdings erscheinen mir die Aussagen von ut und benuzterplutzer glaubwürdig, da sie dies mit einigen Details untermauern konnten."

hab ich aufgehört zu lesen... Schlimm? :D

Sry, aber nachdem ich nunmal die x86_64 Spezifikation gelesen habe (und nicht nur die Tabellen angeguckt hab ;)), mir den Source-Code angeguckt habe und das Dokument/Vortrag es noch mal grafisch verdeutlichte, hab ich da recht wenig offene Fragen ;)

Coda

2008-01-02, 23:41:43

Hier gibt es den Vortrag als Video:

http://ftp.uni-kl.de/24C3/mp4/24c3-2303-en-inside_the_macosx_kernel-COMPATIBLE.mp4
Das Aussehen (nicht positiv oder negativ, nur der Stil) der Frau im Zusammenhang zu dem was sie redet wirkt auf mich irgendwie ein ein Fehler in der Matrix ;D

Ganon

2008-01-02, 23:46:55

Sei ehrlich, du bist scharf auf sie :D :D Nein, Spaß :D War für mich auch ein komisches Bild... aber naja... ich glaub die Haare sind nicht echt xD

Schnuller4u

2008-01-02, 23:51:38

hab ich da recht wenig offene Fragen ;)
Welche Fragen bleiben denn bei Dir offen?
:whistle:

Schnuller4u

2008-01-02, 23:55:04

Das Aussehen (nicht positiv oder negativ, nur der Stil) der Frau im Zusammenhang zu dem was sie redet wirkt auf mich irgendwie ein ein Fehler in der Matrix ;D
Hier, für Dich! :love2: ;D
http://www.macmacken.com/wp-content/files/24c3_001.png

Coda

2008-01-03, 00:28:13

Sei ehrlich, du bist scharf auf sie :D :D
Nein wirklich nicht, aber die sieht aus als hätte man sie frisch vom Strich geholt :|

Und dann so ne Geek-Rede. Das erträgst doch nicht...

Schnuller4u

2008-01-03, 01:38:00

Aus meinem Link:

Fazit: Auch wenn große Teile von Xnu 32bit sind, ein kleiner Teil ist es nicht. Dieser ermöglicht einen sauberen Wechsel zwischen den Modi soweit es den User-Space angeht.

Was den Rest des Kernel betrifft bleiben Fragen offen:

Wieviel von Xnu steckt im 64bit-Teil? Der ganze Mach Micro-Kernel?

Sind der 64bit und der 32bit Teil ein Task (im Sinne der Prozessorregister) oder sind es zwei. Ich bin immer davon ausgegangen, das man bei x86 IA32 und AMD64 Code in einem Task nicht mischen kann (beim PowerPC ging dies). Demnach müssten es zwei Tasks sein. Kann ein (CPU)-Task den Priviligue-Ring wechseln?

Letzlich ist das Problem nicht gelöst nur verschoben, nämlich dahin: Wie kann der Kernel 32bit udn 64bit-Code in sich mischen?

Kann dazu jemand etwas sagen bzw. mal das komplette Konzept zusammenfassend erläutern?