ARCHIV 1999-2006

ARCHIV :: # 2158

Panther: 64 bit oder nit?

Von Brücken und Migrationspfaden

Autor: kai - Datum: 07.07.2003

Laut neuesten Informationen von The Register wird Panther genau wie 10.2.7 ("Smeagol") kein volles 64bit-OS sein. Ehrlich gesagt verwundert mich das kein Stück, denn Apple wird nicht einen kompletten 64bit-optimierten Rewrite nur für Panther auf G5 machen, was ja zu 95% auf G3/G4-Rechnern laufen wird.
Was allerdings in Panther sein wird sind diverse Libraries und Systemroutinen in 64bit, die davon profitieren können (Ich denke es handelt sich hier um mathematische Bibliotheken oder die ganzen "Bausteine" von Cocoa!). Somit kann jedes Programm indirekt 64bit nutzen ohne explizit dafür vom Programmierer optimiert werden zu müssen.
The Register schreibt, dass für die einfache Migration IBM eine 64bit-Bridge in den P970 eingebaut hat, die gewisse Aspekte und Verhaltensweisen von 32bit-PPC im 64bit-Modus erlaubt, die ansonsten nicht gestattet wären. Obwohl PPC von Anfang an für 64bit designt war gibt erst diese Bridge dem G5 seine volle 32bit-Kompatibilität und verhindert, dass alle ihre Programme komplett rekompilieren und umschreiben müssen um 64bit-Features nutzen zu können. Ein G5 kann allerdings soweit ich das umrissen habe wenn jemand 64bit nutzen will in einem 32bit-Programm auf den vollen 64bit-Modus umschalten um davon profitieren zu können. Hierfür wird ein Check durchgeführt, und wenn kein 64bit-PPC da ist wird der normale 32bit-Code hergenommen. Somit eine Art Fat Binary, aber eben nur teilweise mit 64bit-Code, nicht mit dem kompletten Programmcode wie damals bei 64k/PPC Fat Binaries. Es ist eher wie Altivec zu sehen, was ja bei Nichtvorhandensein einer Altivec-CPU auch auf normalen skalaren PPC-Code "ausweicht", aber nur bei den entsprechenden Routinen.

Was den adressierbaren Speicher angeht: Dank dieser Bridge kann ein 32bit-Programm den vollen 42bit-Adressraum adressieren, den Apple für den G5 vorgesehen hat, es muss dann allerdings schon für den G5 optimiert (aber nicht 64bit!) sein.

Mit der Bridge soll vermieden werden, dass für den G5 eine extra 64bit-Codebase gepflegt werden muss, es soll somit die Migration so einfach wie möglich gehalten werden.

Diese 64bit-Bridge ist nur temporär, damit man ohne einen kompletten 64bit-Compile schon 64bit-Features (grösserer adressierbarer Speicherbereich, höhere Präzision) nutzen kann und soll nach der Migration auch wieder rausfliegen, IBM betont explizit dass diese Bridge kein Teil der PPC-ISA ist.
Da G3s und G4s noch viele Jahre im Einsatz sein werden denke ich, dass wir hier locker von einem Zeitraum von 8 oder mehr Jahren reden, man denke nur mal zurück, wie lange es gedauert hat, bis Apple allen 68k-Code losgeworden ist!

Trotz der Bridge wird es natürlich trotzdem möglich sein, G5-only 64bit-Programme kompilieren und laufen zu lassen, was z.B. wichtig ist für Programme, die aus dem 64bit-Workstationbereich (Sun, SGI, Alpha) portiert werden, die stark auf 64bit setzen.

Was ich mir persönlich vorstellen kann ist, dass Panther allerdings schon mit einem Compiler gebaut ist, der gewisse Sonderfälle, unter denen der G5 schlecht performt vermeidet und der allgemein (32bit-Code!) für den G5 produziert, der z.B. die "Fünfergrüppchen" des G5 immer schön vollmacht und so die CPU gut auslastet. Wie gut dieser Code auf G3s und G4s läuft kann ich leider nicht sagen, aber was man so hört soll Panther jetzt schon ziemlich fix auf G3s/G4s laufen!

Es ist also wie vermutet: Von 64bit sollte man sich anfangs nicht so arg viel erhoffen ausser mehr Speicher, und manchmal gehörte Sprüche wie "ich kauf mir erst nen G5 wenn auch OS X voll 64bit ist!" sind illusorisch, denn ein reines 64bit-OS X werden wir in diesem Jahrzehnt wohl nicht mehr sehen. Es ist ja auch nicht so als würden wir das unbedingt brauchen um vom G5 zu profitieren, der Chip hat schliesslich weit mehr zu bieten: Viel mehr MHz-Potential, dramatisch schnellere Busse, 512kb L2-Cache, mehr Execution Units (2 FPUs!), einen viel viel besseren Lookahead-Buffer und selbstoptimierende Fähigkeiten für schlechten Code!
Die Leute halten immer 32bit-Code für das Äquivalent zu 68k-Code (auf Mac) und 16bit-Code (auf Windows) wenn sie an den Schritt zu 64bit denken. Was dabei allerdings immer vergessen wird ist, dass mit 32bit in fast allen Fällen keinerlei "Knappheit" herrscht weil die verrechneten Zahlen zu gross sind, was bei 16bit sehr wohl der Fall war, denn grössere Zahlen als 65536 (=16bit-Register) kommen dann doch recht häufig in Programmen vor, grössere Zahlen als 4294967296 (=32bit-Register) eher selten!

Und wer noch mehr über IBMs G5-Roadmap erfahren will, soll sich mal das hier durchlesen. Aber vorsicht, nicht zu sehr reinsteigern: Alles nur Gerüchte! Aber wie wir ja vom Gobi oder vom G5 selbst wissen, liegen die Gerüchteköche oft gar nicht so falsch! ;-)

Kommentare

Oha

Von: Thyrfing | Datum: 07.07.2003 | #1
da kriege ich ein wenig Angst, wenn ich das lese.
Das erinnert mich an die M$ System .dll's, die nie zusammen funktionieren, zumindest nicht so wie sie sollen.
Oder liegt der Fall hier gänzlich anders?

Ich sag's gleich: Schreibt langsam, denn ich kann a) nicht so schnell lesen, b) habe ich eigentlich null Ahnung, wie einige hinterher bestimmt behaupten werden.
Das sage ich schon mal vorher, dann könne sich die Trolle den Kommentar sparen, denn ich bin doof!

Zurück zum Thema. Also, können die "Bausteine" kollidieren, wie die dll's, oder ist hier durch den Unix Unterbau (der hoffentlich in Panther erhalten geblieben ist) Sicherheit gewährleistet?
Thyr

Hast du jemals einen Absturz auf nem G3 wegen Altivec gehabt? ;-)

Von: Kai (MacGuardians) | Datum: 07.07.2003 | #2
..oder einen DLL-Konflikt?
Nein? Dann wirst du auch hiervon nix merken! ;-)

DLLs sind Software, IBMs Bridge ist im Chip und hat ihr Gegenstück im Compiler (den man braucht, um die 64bit-Features in seinen 32bit-Programmen nutzen zu können!) und der Compiler spuckt den entsprechenden Code als Binary aus, völlig ohne eigene DLLs etc!
Libraries sind was ganz normales (können natürlich auch mit so nem Compiler kompiliert werden!), nur ist M$' Library-Verwaltung eben komplett für'n Arsch! ;-) Die von OS X ist eben viel besser, weswegen man auch niemals Library-Fehler angemault bekommt, und dabei wird sich auch beim G5 exakt gar nix ändern!...

Hehe

Von: Thyrfing | Datum: 07.07.2003 | #3
zu dem G3 kann ich nix sagen, ich hatte nie einen....;-)

Und ein Wort in Steve's Ohr!

Danke für die laaaangsaaaaame Erklärung :-)

Thyr

"Und dein Wort" soll es heißen

Von: Thyrfing | Datum: 07.07.2003 | #4
Genau ;-)

64bit OS

Von: T1000 | Datum: 07.07.2003 | #5
Kann man eigentlich davon ausgehen, daß wenn es eine 64bit Version von OSX gibt, es keine 32bit Version mehr geben wird oder ist dieser Aufwand zwei verschiedene OSs zu pflegen garnicht so groß?

mfg

Naja,

Von: T1000 | Datum: 07.07.2003 | #6
Ich glaub ich sollt erstmal den Artikel lesen und dann schreiben.
War mal wieder etwas zu voreilig. *gg*

cu

@T1000

Von: AppleKing | Datum: 07.07.2003 | #7
T1000 sehr gut, schön dass Du deinen Fehler gemerkt hast, oder wie es so schön heist, erst lesen, dann nachdenken und dann vielleicht auch mal posten.. :-)

@Kai Qualität des Beitrages

Von: tjp | Datum: 07.07.2003 | #8
Hast Du jemals einen Compiler benutzt oder ein OS mit 32Bit und 64Bit Umgebung wie etwa Solaris >= 7, IRIX 6.5.x, AIX 5.xL, HP-UX >= 11.00?

Ich denke nein.

1)
Wenn Software pure ISO C/C++ und Single UNIX Spec konform ist, dann muß man sie nur neu compilieren damit sie sowohl unter 32Bit wie auch 64Bit Umgebung läuft.

Das fällt unter das Thema wie schreibe ich portable Software.
2)
Cocoa ist sauber geschrieben und OpenStep lief früher auf verschiedenen Plattformen NT, NEXTSTEP, Solaris.

3)
32Bit und 64Bit Applikationen können keinen gemeinsamen Adreßraum benutzen. Das heißt, 64Bit PlugIns für 32Bit Apps gibt es nicht. Der Artikel von TheReg ist in dieser Hinsicht schwamming und vermutlich einfach Mist.

Andere Formen von IPC müssen genutzt werden. Was es so an IPC unter UNIX gibt und was in einem getrennten Adreßraum läuft siehe W. Richard Stevens, UNIX Network Programming, Interprocess Communications (IPC)

4)
Ein 64Bit Kernel verlangt 64Bit Treiber. Damit sind Treiber gemeint, die im Kernelspace laufen. Bzgl. MacOS X sind das vorallem kexts. Druckertreiber und ähnliches läuft im Userspace. Das interessiert nicht.

5)
Der UNIX Source Code egal ob System V Code von AT&T oder *BSD ist 64Bit clean. Dazu kommen so gut wie alle UNIX Tools, die Apple als BSD Subsystem bezeichnet. Die müssen einfach nur als 64Bit App compiliert werden. Das ist alles.

6)
Das Photoshop PlugIn von Adobe wird vermutlich nur 32Bit Code für PPC970 enthalten haben, damit PS schneller auf einem PPC970 läuft.

4GB vs. 8GB

Von: iCalvin | Datum: 07.07.2003 | #9
Genau wie bei der "Apple übertaktet PPCs"-Debatte wird es auch hier mal dringend Zeit für einen klärenden Artikel mit der Überschrift: "Wann ist ein System ein 64 Bit System". Freiwillige vor :)

So wie es im Moment aussieht wird Panther nur "minimal" an eine 64 Bit Umgebung angepasst, bei John Stokes im macnews.de-Interview war zu lesen, dass noch nicht mal sicher ist, ob EIN Prozess mehr als 4GB bearbeiten darf.

Das ist bisher eigentlich der einzige wirklich interessante Vorteil eines 64 Bit Systems gegenüber einem 32 Bit System. Der größere Zahlenraum etc. ist wirklich nur in eher esoterischen Anwendungen aus dem wissenschaftlichen Bereich von Interesse (und vielleicht mal bei 3D Renderings wenn ernsthaft mit mehr als 24 Bit/32 Bit gerendert wird).

Ich denke übrigends das die meisten Macuser diese "Einschränkung" nicht merken werden, bislang bin ich noch in keinem Photoshop-Projekt an diese Grenzen gelangt.
(Übrigens: Mac OS 9 hatte sein Limit bei 1 GB pro Prozess, auch wenn das System insgesamt mehr verwalten konnte)

Gruß
iCalvin

Panther ist 32-bit

Von: vowe | Datum: 07.07.2003 | #10
Eigentlich ist das noch viel einfacher. Panther ist ein 32-bit OS. Der neue G5 (System, nicht Prozessor) ist ein 64-bit System, das 32-bit Code ausführen kann. Deshalb läuft die alte SW ohne Recompilierung. Wird Apple auch ein 64-bit OS machen? You bet. Nur haben sie das noch nicht angekündigt.

Einige Spekulationen zur Nacht

Von: Rüdiger Goetz | Datum: 08.07.2003 | #11
Hallo,

Die Hauptfrage ist doch, wie diese 64bit-Bridge aussheen könnte, die 32bit mit "64-bit" Addressen laufen lässt. Wobei 64bit-Addressen wohl in erster Linie meint mehr als 4 GB und wenns nur 8 oder 16 GB werden. Das würde fürs erste reichen.

Nun, zum einen addressiert bei UNIX (und vermutlich nicht nur dort) eine Appliktion ihren Speicher über virtuelle Addressen. Bei 32 bit-Apps sind die eben 32 bit und ergeben ca 4GB RAM für eine App (es geht wohl ein klein wenig etwas für Einsprungaddressen des Systems weg).Nur wo diese Addressen im Speicher liegen regelt die MMU in der CPU. Und die dürfte intelligent genug sein dies irgenwo in der 64bit-Raum zu mappen. Sei ist ja Teil einer 64 bit CPU. Damit können also 32bit-Apps also an beliebiger Stelle im Speicher liegen. 4 GB 32 bit-Apps in 8GB wären also kein Problem. Das wäre aber auch nichts was man eigentlich extra erwähnen müsste.

Nun zu den Spekulationen. Beim PPC sind im 32 bit-Modus zwar die Addressregister nur 32 bit breit, die integer GPRs aber 64bit ! (schon immer gewesen). Vielleicht lässt sich darüber etwas drehen. Oder bei Addressberechnungen kann es theoretisch ja passieren, dass der Wert über den 32bit Raum wächst (32bit Basis-Addresse + 32bit-Offset ergeben eine Addresse im 33bit-Raum) Bei einer echten 32 bit CPU gibt das Ärger , aber eine 64bit-CPU könnte intern richtig Rechnen, also quasi die überläufe mitführen. Allerdings müsste das Programm das auch irgendwie mitbekommen können, da es plötzlich zwei scheinbar itdentische Addressen hat.

Eine andere Variante (die aber das mitspielen des Compiler erfordern würde, aber das scheint ja der Fall zu sein): Jedes Programm besteht aus mehereen Seqmenten, dem Programmsegment, in dem der eigentlich Maschinencode steckt, dem Datensegement in dem die Daten stecken mit denen gerechnet wird, den Konstantenbereich und den Stack. Denknbarwäre, das diese Bridge jedem dieser Bereiche einen eignen 4GB-Addressraum zur Verfügung stellet. Je nach Applikation wären dass dann nur wenig mehr als 4GB bis ziemlich viel mehr.

Noch ein Trick, den ich mir vorstellen könnte (setzt wieder das mitspielen von Compiler und libc voraus). Wenn Speicher für ein Array angefordert wird, liegen die Addressen dichter bei einander, als sie nach der Größe der angeforderten Speicherblöcke dürften. Die MMU mapt das aber entsprechend. Damit sie das tun
kann muss der Compiler aber der MMU sagen, um welchen Speicherblock es sich handelt.

Und noch eines, was vielleicht wenig bekannt ist. Auch die PPCs haben Segementregister (zumindest die 603/4 hatten). Mit diesen liessen sich unter Umständen verschiedene Speichersegmente unterscheiden, die auf einer 64bit-Maschinene bis zu 4 GB gross werden können, auf einer 32bit eben nur zusammen 4 GB ergeben dürften.

Auch wenn das alles nur Spekulatione war, scheint mir eines recht klar zu sein. Das ganze geht nur bei einem Zusammenspiel von Compiler, Speicherverwaltung des Systems (vor allem der libc) und der Bridge in der CPU. O.K. das ist nicht neu, aber anders gehts es wohl wirklich nicht.

Bis dann

R"udiger

@Rüdiger Götz Spekualtionen

Von: tjp | Datum: 08.07.2003 | #12
Will soll eine bestehende Applikation einen Adreßraum größer 32Bit addressieren können?

Es geht nicht. Der Platz im Code reicht nur für 32Bit aus, irgend welche Tricks können nicht funktionieren, da im Programmcode keinerlei Information mehr vorhanden ist wie groß Zeiger sind und wie bestehende Datenstrukturen anztupassen wären. Dazu braucht man den Sourcecode oder so etwas wie den ByteCode von Java. Das ist eindeutig nicht der Fall.

Neucompilieren MUSS daher sein. Und wenn man das macht kann man gleich den Adreßraum auf 64Bit umstellen. Ob die CPU nun 42Bit, 44Bit oder echte 64Bit Adreßleitungen unterstützt ist egal, da sie das mit dem OS zusammen verwaltet.

Irgend welche Unsinn über Bankswitching wie zu den 8Bit/16Bit Zeiten macht man mittlerweile nicht mehr.

@tjp

Von: Rüdiger Goetz | Datum: 08.07.2003 | #13
Hallo,

Nicht jedes Programm ist a priori 64bit-clean.
Mitunter werden dreckig Tricks mit integer Variablen gemacht, die sich darauf verlassen, dass Pointer, wie integer 32 bit haben.
Oder beim binären Speichern (fwrite/fread) von structs und Klassen. Wenn ein Pointer darin nun
doppelt so breit ist, stimmt die Größe der Datenstruktur auf der Platte nicht mehr (ja ich weiss es macht keinen Sinn einen Pointer auf Platte zu sichern, aber manchmal ist es einfacher es doch zu tun und nach dem Laden den Pointer korret zu setzen).


BTW: Bei C/C++ sind die Breiten der einzelnen Datetypen ja nicht plattformübergreifend definiert. Wie breit ist den ein nun ein integer 32 oder 64 bit. Wenn er 64 bit breit ist, kann es auch zu Problemen kommen (z.B. Wegfallen des Impliziten Modulo bei linear congruential PRNGs)

Wenn es da einen Compiler mode gibt, der ggfs auch durch Hardware unterstützt wird, der eine Anpassungen vorhandener Software an 64bit System erleichtert, wäre das schon eine Hilfe.

Und sowas gab es schon mal. Ich erinnere mich an meine Zeit beim MPI. Dort hatten wir verschiedene SGIS mit R4400er-CPU (die aus irgendeinem Grund nur 32 bit Apps konnte) und
R10000er-CPU (die voll 654bit fähig war).
Der SGI-Compiler bot damals drei Modi an. Altes 32bit, neues 64bit und Mix-Mode oder neues 32bit, d.h. Programme liefen auf 32 und 64bit Maschinen (min. ab R4400), waren zwar damit 32bitig, konnten aber Vorteile der 64bit-Plattfform ausnuzten.

Bis dann

R"udiger


BTW: Mein Nachname schreibt sich wirklich mit 'oe' nicht 'ö' . Scheit sonst irgendwie so kurz aus ;-)

Applepfusch

Von: TheBurgerKing | Datum: 08.07.2003 | #14
Es zeigt doch nur das Apple hier nur rumgepfuscht hat und eine Rechner Generation auf den Markt gebracht hat, für die es noch gar kein Betriebssystem hat.

Aber halbe Sachen sind wir ja bei Apple gewohnt. Aber wer weiss, vielleicht wirds ja was ?

Erfahrungsgemäß muss man dann jedoch sehr viel für die Abwärtskompatiblität einprogrammieren was die Software meist sehr instabil und unnötig langsam macht. Der Schnitt ist hier schwer, die G3s dürfte dann wohl auf der Strecke bleiben...

@Rüdiger Goetz 64Bit Programming

Von: tjp | Datum: 08.07.2003 | #15
C89 und C++98 unterstützen das nicht, das ist richtig, C99 tut es! Aber ich habe extra von der Single UNIX Spec geschrieben, die unterstütz das explizit seit Version 2 und die Vorgänger Releases haben auch schon Unterstützung dafür mitgebracht.

In den entsprechenden Header wird definiert wie groß ein Pointer ist und wie groß die jeweiligen Datentypen sind. Dazu werden Typen definiert, die eine vorgegebene Breite haben 16, 32, 64 oder 128Bit.

Es ist kein Problem auf einem Single UNIX Spec konformen OS Software zu schreiben, die sich neutral zur Zeigerbreite verhält. Man muß nur wissen wie man das machen muß. Wenn man Datenstrukturen auf die Platte wegschreibt muß man sich mit dem Thema auseinander setzen und etwas schwierigen wird es, wenn man Datenstrukturen jeweils in 32Bit und 64Bit Apps benutzen will.

Zum Thema IRIX
Es gibt von MIPS die R2k (ISA I), R3k (ISA II), R4k und R5k (ISA III), R8k, R10k und neuer (ISA IV) CPUs. Ab der R4k sind das 64Bit CPUs. SGI hat aber erst ab dem R8k 64Bit Laufzeitumgebungen für IRIX angeboten. Und das auch erst mit einige Verzögerung.

Es wurde das Binärformat beim Wechsel von der ISA I, II auf ISA III, IV geändert. Man hat also unter IRIX 6.5.x o32 Code/Libs (ISA I & II), n32 Code/Libs (ISA III & IV), n64 (ISA III & IV). n64 wird nur als 64 bezeichnet und man kann Code für ISA III erzeugen, obwohl es nie 64Bit RunTime Support für diese CPUs gab.

Der Hauptunterschie zwischen den alten ISA I, II und ISA III, IV besteht darin, daß man mit der neuen ISA mehr Register ansteuern kann und mehr Befehle zur Verfügung hat.

IRIX 6.5.x hat nun drei RunTime Umgebungen, o32 für Legacy Apps, damit diese auch noch unter IRIX 6.5.x laufen, n32 für 32Bit Apps und 64 für 64Bit Apps (nur auf R8k und neuer). IRIX 6.5.x selbst läuft nur auf R4k und neuer.

Ich habe IRIX seit 6.2 benutzt und das hatte als Default Format n32. IMO stammt o32 noch von IRIX 5.3, davor wurde COFF statt ELF benutzt.

Re: Apfelpfusch

Von: tjp | Datum: 08.07.2003 | #16
Herrje,
wann lernt Ihr es! Es ist kein Problem ein OS sowohl für 32Bit wie 64Bit Umgebungen zu schreiben. Jedes kommerzielle UNIX für 32Bit und 64Bit Hardware hat sowohl eine 32Bit wie auch eine 64Bit RunTime Umgebung dabei, da sonst die alten Programme und die neuen (die Vielzahl der Apps läuft auf einem 64Bit Computer nur als 32Bit!!!) nicht mehr laufen würden. Auf den 32Bit Computer fehlt die 64Bit Umgebung, mangels Hardwaresupport auch kein Wunder.

Der ganze Aufwand reduziert sich darauf verschiedene Computer im Kernel zu supporten. Und für Fremdanbieter reduziert sich der Aufwand darauf Treiber (nur kext, Druckertreiber o.ä. fallen da nicht drunter) sowohl als 32Bit wie auch 64Bit vorzuhalten. Wenn es überhaupt einen 64Bit Kernel geben wird, das muß man erstmal abwarten.

@tjp

Von: Eädiger Goetz | Datum: 08.07.2003 | #17
Hallo,

Nun ich bin damals (1994) mit IRIX 5.3 eingestiegen, später haben wir dann alles auf (galub ich) IRIX 6.4 oder 6.5 geupdated. Alles 6.xer davor waren ja nur für bestimmte Maschinen (Kennt man iregendwie auch aus der Apple Historie). Wir hatten somit noch viele o32-Apps, bzw. mussten unsere Compiler-Calls entsprechend umstellen.

Noch mal zur "IBM-Bridge": Wenn es sie wirklich gibt, werden wir ja wohl irgendwann erfahren, wie sie funktionieren soll. Warten wir es also ab.

>C89 und C++98 unterstützen das nicht, das ist richtig, C99 tut es!

Worauf hast du dich hier bezogen. Ich hab irgendwie den Faden verloren. 64bit kann es doch nicht sein, da das letztlich schon von K&R-C unterstüzt wird. Es ist eben (zumindest bei K&R) nicht definiert, wie breit ein int, float etc ist. In 16bit-Umgebungen war ein int eben 16bit breit, ein long int 32bit breit, bei 32bit Umgebungen waren bei 32bit (und nur long long int war 64 bit). Sinnvoll fände ich wenn int 32 bit bliebe und long int zu 64 bit geadelt würde (so hat es AFAIR SGI so gemacht).

Und noch zu Apfelpfusch: Ich bin davon ausgegangen, dass er mythischer Norweger ist und wollte ihn nicht füttern. Andereseits war es vielleicht ernst gemeint. Der beste Umgang mit mythischen Norwegern ist vielleicht wirklich genau eine sachlich Antwort geben und gucken ob er weitermacht oder vernünftig diskutiert.

Bis dann

R"udiger

64 noch zu wenig

Von: at | Datum: 08.07.2003 | #18
> 64k/PPC Fat Binaries

In diesem Fall sind 64 wohl noch zu wenig. Stell dir vor, Kai: Es waren gigantische 68 ;-)

@tjp

Von: Leo | Datum: 08.07.2003 | #19
Schön, dass jemand die Schwachstellen im Register-Artikel (oder eher in Kais Übertragung?) aufzeigt.
Das durfte so nicht stehen bleiben.

Elefantenrunde:

Von: Kai (MacGuardians) | Datum: 08.07.2003 | #20
Na da haben sich ja zwei Unix-Schwergewichte getroffen! ;-)

Macht ruhig weiter, ich lese sehr interessiert mit, hehe!

Und nein, natürlich hab ich noch nie selbst nen 64bit-Compiler eingesetzt (wie kommst du drauf?), das einzige was ich mit 64bit jemals zu tun hatte war an ein paar Alphas rumschrauben und ab und zu ne SGI bewundern! ;-)

Aber ist das was TheReg schreibt wirklich falsch? Ich denke nicht, auch wenn es nicht die Tiefe hat, in der ihr hier diskutiert, oder?

@kai The Reg Artikel

Von: tjp | Datum: 08.07.2003 | #21
Der folgende Abschnitt im Artikel ist einfach nur Käse. Das _kann_ nicht funktionieren. Eine 32Bit App kann auf einem 64Bit System nicht mehr Arbeitsspeicher als einen 32Bit Adreßraum ansprechen.

>The upshot that a 32-bit app can gain access to
>a much larger address space than it by rights is
>able to, though it has to be optimised for the
>970 first.

Man kann das nur ändern, wenn man größe Zeiger benutzt und dann nimmt man gleich 64Bit Zeiger ->64Bit Apps, oder man würde irgend einen Mist ala Bank Switching wiedereinführen. Das macht garantiert niemand, viel zu kompliziert.

Alle 64Bit PowerPCs egal ob PowerPC RS64 I bis IV, PPC620, POWER3 (PPC630), POWER3-II, POWER4, POWER4+ oder PPC970 verfügen über die Möglichkeit sowohl 32Bit wie auch 64Bit Kernel auszuführen.

32Bit Applikationen laufen in ihrem eigenem virtuellen Adreßraum, was unter einem UNIX vollkommen normal ist. Dieser Adreßraum ist in Pages aufgeteilt und jeder dieser Speicherseiten darf irgend wo im physikalischem Adreßraum liegen. Die PMMU mappt bei jedem Speicherzugriff die logische virtuelle Adresse auf eine physikalische - notfalls werden Seiten vorher aus dem Swap ins RAM geholt.

Dabei werden 32Bit logische (virtuelle) auf 42Bit (beim PPC970) physikalische Adressen gemappt. Aber das ist weder irgend etwas besonderes noch irgend wie was besonderes was auch nur der Erwähnung wert wäre. Die Adreßraumbeschränkung auf 32Bit bleibt trotzdem bestehen!

viel spass

Von: betatesta | Datum: 09.07.2003 | #22
wünsche ich den zukünftigen g5 käufern
beim testen der verschiedenen apps

ich warte ab bis ich aus diversen mac-foren ein go bekomme
und erst dann werde ich überhaupt an einen g5 kauf nachdenken