Macs sind nur noch gewöhnliche PCs

mattmiksys schrieb:
wenn's man eine gewesen wäre...

Es war eine. Solange bis ._ut Tatsachen einfach ignoriert hat...
 
lundehundt schrieb:
._ut als Troll zu bezeichnen zeugt entweder von einem voellig anderen Verstaendnis dafuer was ein Toll ist oder du hast nicht wirklich was von ._uts 8000 Beitraegen hier gelesen.

...

Als Troll würde ich ihn nie bezeichnen, aber die Deutung des Wortes hat in ihrer ursprünglichen Bedeutung so oder so immer mehr gelitten. Aber er hat schon eine seltsam eigenwillige Art und Weise Dinge recht einseitig zu interpretieren und sich dann gekonnt auf diesen Zweig zu äußern. Das ändern nichts an der Tatsache, das er bei einigen Dingen schlicht weg nicht recht hat und die, wo er es hat, als globale Bestätigung wertet. Das sowas einigen als sehr überheblich erscheint sehe ich dann als verständlich an, wer dann nicht in der Lage sich weiterhin in Ruhe zu äußern, der mag zwar durchaus Beiträge verfassen die den richtigen/korrekten Inhalt haben, erscheint aber für die, die das nicht nachvollziehen kann als "unterlegen". Genau darauf zielen dann auch einzelne Aktionen von ._ut ab und das mag andere zum kochen bringen, andere geniessen es. Jeder so wie er beliebt.

Deswegen bringt uns das alle nicht weiter, wenn es weiterhin auf dieser Ebene stattfindet. Vielleicht oder besser gesagt ganz sicher ist es das Beste, wenn sich jeder einfach auf das Threadthema konzentriert und den Leser selbst entscheiden läßt wer/wann/wie richtig liegt.
 
vielleicht hast du auch nur die selektiven und wenig representativen quotes von ._ut im 3DCenter gelesen....Er scheint da ja schon laenger ein rotes Tuch zu sein

Und was ist on-topic. Ich denke nicht dass sich irgend jemand ausser Coda den "Spielstand" notiert hat.
 
Ich habe hier bei MU recht viel gelesen! So damit es endlich weitergeht und dieser OT-Kram aufhört!

"Effective address calculations, for both data and
instruction accesses, use 64-bit two's complement
addition. All 64 bits of each address component participate
in the calculation regardless of mode (32-bit
or 64-bit). In this computation one operand is an
address (which is by definition an unsigned number)
and the second is a signed offset. Carries out of the
most significant bit are ignored.

In 32-bit mode, the low-order 32 bits of the 64-bit
result comprise the effective address for the purpose
of addressing storage. The high-order 32 bits of the
64-bit effective address are ignored
for the purpose of
accessing data, but are included whenever an effective
address is placed into a GPR by Load with Update
and Store with Update instructions. The high-order 32
bits of the 64-bit effective address are effectively set
to 0
for the purpose of fetching instructions, and
explicitly so whenever an effective address is placed
into the Link Register by Branch instructions having
LK=1. The high-order 32 bits of the 64-bit effective
address are set to 0
in Special Purpose Registers
when the system error handler is invoked. As used to
address storage, the effective address arithmetic
appears to wrap around from the maximum address,
232 − 1, to address 0 in 32-bit mode.


The 64-bit current instruction address and next
instruction address are not affected by a change from
32-bit mode to 64-bit mode, but they are affected by a
change from 64-bit mode to 32-bit mode. In the latter
case, the high-order 32 bits are set to 0."

Quelle. Band 1 runterladen, Abschnitt 1.12.1 lesen.

Ansonsten auch Abschnitt 3.3.7 beachten.
Im 32-Bit-Modus werden die hohen Bits durch Arithmetik uU geändert aber sie werden ignoriert. Flags zB:
"In 32-bit mode, these bits are set by signed
comparison of the low-order 32 bits of the result to
zero."

Negation zB:
"The sum ¬(RA) + 1 is placed into register RT.
If the processor is in 64-bit mode and register RA
contains the most negative 64-bit number (0x8000_
0000_0000_0000), the result is the most negative
number and, if OE=1, OV is set to 1. Similarly, if the
processor is in 32-bit mode and (RA)32:63 contain the
most negative 32-bit number (0x8000_0000), the loworder
32 bits of the result contain the most negative
32-bit number and, if OE=1, OV is set to 1."

Das Problem mit dem 32 Bit-"Kernel" (gleich ...) und den 64 Bit-Registern gibt's deswegen nicht, weil die breiten Registerinhalte auch im 32 Bit-Modus vollständig in den Speicher geschrieben und wiederhergestellt werden können. So wie bei x86 eben auch MMX- und FPU-Register gesichert und gelesen werden können, wobei das da noch viel weniger mit dem Modus zu tun hat. Trotzdem ist die Parallele so falsch nicht. Denn der G5 kann im 32 Bit-Modus keine Adressen erzeugen die breiter als 32 Bit sind, und er kann nicht zuverlässig mit Zahlen rechnen die breiter sind, wie ich im vorletzten Beitrag auch schon aus der Doku zitiert habe.

Das ginge theoretisch noch im 32 Bit-Modus. Was allerdings nun gar nicht mehr geht ist die Speicherverwaltung, Paging, und der ganze Rattenschwanz der daran hängt. Dafür muss das Teil schon in den 64 Bit-Modus wechseln.

Absoluter Knüller, Abschnitt 5.4 "Interrupt Processing" aus Band 3:
"Interrupt processing consists of saving a small part of
the processor's state in certain registers, identifying
the cause of the interrupt in other registers, and continuing
execution at the corresponding interrupt
vector location.

<...>

4. The MSR is set as shown in Figure 28 on
page 54. In particular, MSR bits IR and DR are
set to 0, disabling relocation, and MSR bit SF is
set to 1, selecting 64-bit mode
. The new values
take effect beginning with the first instruction
executed following the interrupt."

Dh jeder Interrupt und, da IBM das nicht trennt (wie ihr selbst überprüfen könnt), jede Exception versetzt den G5 in den 64 Bit-Modus. Immer. Sofort. Als erstes.

Und dreimal dürft ihr raten wie es ein OS mit präemptivem Multitasking hinbekommt, dass ein Thread schlafen geht, damit auch mal ein anderer rankommen kann.

Also nix mit Task Switching im 32 Bit-Modus. Dieser sagenumwobene 32 Bit-Kernel würde nicht funktionieren, wenn er nicht 'ne ganze Menge Code für den 64 Bit-Modus enthielte, und da wird's doch langsam absurd.

So... und weil hier immer so argumentiert wird auf der Schiene "Buchautor" usw. mach ich das mal genauso!
Das hier ist von Zeckensack, u.a. dem Programmierer von ArchMark und einem Glide-Wrapper!
 
Zuletzt bearbeitet:
Nur zur Vollständigkeit:


._ut schrieb:
Es gehört wohl auch zum Spiel, Leuten Worte in den Mund zu legen und eigene Aussagen soweit zu verdrehen, nur, damit man einen Sieg empor tragen kann.

Ja, ist echt nicht schön, was du hier andauernd machst... :rolleyes:

._ut schrieb:
- Ich habe nie von einem IBM-kompatibeln BIOS gesprochen. Vielmehr habe ich mehrfach versucht, den Unterschied zwischen BIOS und BIOS-Interface zu erklären. Entweder ist er nicht in der Lage, das zu verstehen oder er will willentlich falsches in meine Worte interpretieren (oder beides). Vielleicht sind meine Wort aber auch noch zu kompliziert.

Das Problem ist -> darum ging es einfach nicht. Du hast den Teil der Diskussion einfach "für dich" in diese Richtung gelenkt, obwohl es nichts damit zu tun hatte...

Und? Es ging darum, das du (?) behauptet hast, mit PAE könnte man einem Prozess nicht mehr Speicher zuweisen. Nachdem das widerlegt wurde, hast du einfach das Thema gedreht.

Und zu dem Rest, wegen 64bit. Dabei kannst du ja nun nicht mitreden, da du die IBM-Dokumente ignorierst.... siehe Post einen über mir...[/URL][/QUOTE]
 
Zuletzt bearbeitet von einem Moderator:
lundehundt schrieb:
Im Gegensatz dazu strotzt Coda nur so vor Arroganz - ob das in der Form einem vermutlichen Informatikstudenten angemessen ist mag jeder fuer sich selbst entscheiden
Und wenn ich dir jetzt erzähle, dass ich an Software arbeite die für Transistormessung und Modelling unter anderem von Freescale und IBM verwendet wird? :p

._ut schrieb:
- Ich habe nie von einem IBM-kompatibeln BIOS gesprochen. Vielmehr habe ich mehrfach versucht, den Unterschied zwischen BIOS und BIOS-Interface zu erklären. Entweder ist er nicht in der Lage, das zu verstehen oder er will willentlich falsches in meine Worte interpretieren (oder beides).
EFI ist kein BIOS-Interface, sondern ein Ersatz dafür. Das solltest du mal verstehen.

Den Addressraum nicht, hab ich auch nirgends so geschrieben. Man kann damit trotzdem bis zu 64GiB Speicher in einer App damit verwenden. Und dafür muss man PAE über eine API verwenden.

Das was in dem zitierten Post steht ist nachweislich richtig.
._ut schrieb:
Bei Trollaktionen allerdings nur Verlierer.
Ich hab schonmal gesagt, dass wenn ich trollen wollte ich nicht diesen Nick gewählt hätte - das ist das einzige was ich zu der ganzen Differmierungsaktion hier sagen werde, weil ich es echt nicht nötig hab darauf einzugehen.

Und du kannst dich tausend mal an deinem einzigen Punkt der halbwegs richtig war festkrallen, dass im Kernel auf PPC auch 32-bit-Code ausgeführt werden kann, der Rest ist trotzdem Schwachsinn.

Z.B. sowas.
._ut schrieb:
Unter Tiger laufen 64-bit-Programme mit 32-bit-GUI, diese Strategie geht beim x86 nicht.
Natürlich geht das. Das ist doch kein Kernel-Code.

Odas das bezüglich LinuxBIOS.
._ut schrieb:
Das ist wie das EFI ein Interface, nicht die eigentliche Firmware (die beim x86 nun mal BIOS heißt, bei aber Apple BootROM genannt wird und für die es bei Intel gar keinen Namen gibt).
Das ist definitv falsch, weil das normale BIOS damit komplett ersetzt wird. Als dir das dann zu eng wurde hast du argumentiert die 16 Setup-Instructions für den 32-bit-Modus wären der BIOS.

Wie wärs mal mit ein wenig Einsicht, dann werde ich meinen Ton auch mäßigen.

Ich bin gern behilflich technische Dinge zu klären, aber dann muss man auch handfeste Argumente so hinnehmen, sonst werd ich wirklich stinkig. Es gibt nichts was mir mehr missfällt als Leute die bewusst Unfug verbreiten.

Wenigstens gestehe ich meine Fehler ein. Solltest du auch mal probieren. Man kann sein Gesicht auch wahren wenn man mal was akzeptiert.

Ich mein was hast du denn im Endeffekt von der Ansicht in deiner kleinen Welt, das PowerPC die unglaublich überlegene Architektur ist?

Ich hab überhaupt nichts gegen PowerPC, ich muss auf Arbeit selbst mit damit, PA-RISC und SPARC arbeiten und die Kisten laufen genauso wie die mit x86 - man glaubt es kaum.
 
Zuletzt bearbeitet von einem Moderator:
re

Ja Mac sind nur noch gewöhnliche IBM kompatible PCs. Zumindest auf der Hardwareseite.

Besonders werden sie erst du MacOS X. Und bevor die Leute jetzt wieder genau so sinnlos auf x86 einhaun wie auf Windows, nur weil ihr anders sein wollt werden eure PPCs auch nicht schneller.

Eigentlich ist doch egal was für eine Hardware arbeitet, solang sie das schnell genug tut.
 
Psycho-Dad schrieb:
Besonders werden sie erst du MacOS X.

Da stellt sich dann die Frage:

Wenn ich mir einen billig-Schrauber-PC hole und dort mit den Hacks OS X installiere, ist das dann ein Mac? ;) :D
 
Natürlich, was sonst?
 
Naja es kommt halt auf die Sichtweise an, ein Mac ist ein Computer der Firma Apple. Somit wird wohl ein normaler Aldi PC selbst mit MacOS X noch nicht zum Apple.

Auch bleibt ein Apple eine Apple wenn via BootCamp Windows XP drauf läuft, nur was unterscheidet ihn dann noch von Millionen anderen Dosen auf diesen Planeten? Höchstens das Design und obd das den Aufpreis wert ist muss wohl jeder für sich selbst entscheiden.

Schwierig, jedenfalls verliert ein Apple nicht seine Seele oder Identität nur weil aufeinmal ein oder zwei Bauteile getäuscht werden.

CU
Flo
 
Psycho-Dad schrieb:
...Schwierig, jedenfalls verliert ein Apple nicht seine Seele oder Identität nur weil aufeinmal ein oder zwei Bauteile getäuscht werden.

CU
Flo
Ach doch, für mich schon. Den ersten Mac habe ich gekauft, weil dort der 68000 drin steckte und nicht dieser Kruckel-80x86. Das ist schon das Herz des Rechners, um das es geht
 
Zuletzt bearbeitet:
Ich möchte nicht unhöffliche sein @mattmiksys

Aber was ist deiner Meinung nach so viel schlechter an x86 im Gegensatz zu PPC oder 68000? Ich seh das eher als Evolution als Revolution. Sicher der x86 war nie das eleganteste Design, aber was aus ihm geworden ist kann man nicht verleugnen. Außerdem dann hätte Apple schon mehr als einmal seine Seele verkauft, gab es solche Grabenkämpfe beim Wechsel auf PPC eigentlich auch?

CU
flo

PS: Für mich, und das sehe wohl nur ich so, ist ein Mac ein Gesamtkonzept. Ich schätze das gute Design, liebe MacOS X und bewundere die Problemlosigkeit mit der alles funktioniert. Und solang Apple auch in Zukunft diese Kriterien erfüllen kann bleibe ich gerne deren Kunde, egal auf welcher Architektur:)
 
Naja, damals war der 68000er dem x86 AFAIR auch wirklich überlegen. Ich hatte ja auch einen Atari ST :D
 
mattmiksys schrieb:
Ach doch, für mich schon. Den ersten Mac habe ich gekauft, weil dort der 68000 drin steckte und nicht dieser Kruckel-80x86. Das ist schon das Herz des Rechners, um das es geht

Na ja, gibt ja noch die XBox. Die is doll schnell und ne Heizung braucht man auch nich mehr.

EDIT Okay Oropax wär cool.
 
Psycho-Dad schrieb:
Ich möchte nicht unhöffliche sein @mattmiksys

Aber was ist deiner Meinung nach so viel schlechter an x86 im Gegensatz zu PPC oder 68000? Ich seh das eher als Evolution als Revolution. Sicher der x86 war nie das eleganteste Design, aber was aus ihm geworden ist kann man nicht verleugnen. Außerdem dann hätte Apple schon mehr als einmal seine Seele verkauft, gab es solche Grabenkämpfe beim Wechsel auf PPC eigentlich auch?

CU
flo
Klar hat sich auch der 80x86 gemausert, der 680x0 war aber beispielsweise von Anfang an auf Orthogonalität ausgelegt: Viele breite Register mit weitestgehend einheitlichem Befehlssatz. Dem 8086 war schon sein 8-Bit-Ahn 8080 anzusehen, die um lediglich 4 Bit verschobenen Segmentregister waren nichts Halbes und nichts Ganzes, das nächste Limit schon erkennbar (1 MByte).
Das wäre alles Schnee von gestern, wenn der PC als solcher die Bastellösungen (Interrupt-Controller, Centronics-Schnittstelle) nicht in die Serie geschleppt hätte, die ursprünglich mal auf ein paar hunderttausend ausgelegt war.
Ich sehe Apples Entscheidung als den technischen Schritt zurück, um wirtschaftlich mehrere Schritte voran zu kommen. Und profitiere selbst davon, weil ich zweigleisig arbeite...
 
ste^2 schrieb:
...Ich hatte ja auch einen Atari ST :D
Ich auch (schon auch ein Wegbereiter zum Mac, oder?)!
Das erinnert mich daran, dass ich viel, viel in 68000-Assembler programmiert habe (vor ein paar Jahren noch für den Dragonball). Mit einem Blick auf 8086-Assembler habe ich mir geschworen, das dort nie zu tun!
 
-Nuke- schrieb:
Ja, ist echt nicht schön, was du hier andauernd machst... :rolleyes:
Nein, das mache ich nicht.
(Mit einer Ausnahme, als Performa angefangen hat, rumzuschreien, habe ich tatsächlich seine Worte verdreht.)
Das wird mir allerdings unterstellt.
Problem ist -> darum ging es einfach nicht. Du hast den Teil der Diskussion einfach "für dich" in diese Richtung gelenkt, obwohl es nichts damit zu tun hatte...
Das ist so nicht richtig. Ich habe den Begriff "BIOS" verwendet (welches übrigen Intel selbst für den Itanium verwendet; BIOS-Firmware nicht zu verwechseln mit dem Legacy-BIOS, das die IBM-kompatible Interface liefert.) und man begann auch mich einzudreschen und das Thema zu zerreden, weil man den Begriff offensichtlich nicht mag.
Und? Es ging darum, das du (?) behauptet hast, mit PAE könnte man einem Prozess nicht mehr Speicher zuweisen. Nachdem das widerlegt wurde, hast du einfach das Thema gedreht.
Nein, darum ging es ursprünglich und dann wurde von anderer Seite das Thema gedreht.
Und zu dem Rest, wegen 64bit. Dabei kannst du ja nun nicht mitreden, da du die IBM-Dokumente ignorierst.... siehe Post einen über mir...
Ich ignoriere nicht die IBM-Dokummente. Allerdings ignoriere ich das 3D-Forum, wo irgendwelche Leute (pallo?) meine Zitate herein schmeißen, wo ich pauschal als Idiot bezeichnet werde, dessen Behauptungen immer und zu 100% unrichtig seien - und wo dann in der Diskussion doch herauskommt, dass ich eigentlich doch recht hatte (was aber dort ganz sicher keiner zugeben würde).
Für mich ist das nur ein Forum von Trolls und Fachidioten.

Ich bin aber weder das eine noch das andere.

Ich bin der Meinung, dass man die recht komplizierten Zusammenhänge im Computerbereich in relativ einfache Worte kleiden kann und muss, damit normale Menschen sie in den Grundzügen verstehen können. (Das ist übrigens auch etwas, was ich den Apple-Developer-Dokumenten anrechne, dort findet sich immer eine Erklärung oder Zusammenfassung, die für nicht Diplom-Informatiker verständlich die Funktion beschreibt; siehe die von mir geposteten Zitate zum Thema 64-bit-Mythen.)

Einige Fachidioten sind offensichtlich nicht der Meinung, dass man Zusammenhänge einfach erklären kann. Oder sie wollen das nicht, um ihr Selbstverständnis als jemand, der mehr weiß, als ein normaler Mensch zu schützen. Oder sie sind in ihrer Welt soweit gefangen, dass ihnen die Welt normaler Menschen als schwammig und unangenehm erschein, weil es dort keine MSR bits IR and DR gibt. Einige dieser Leute wollen dazu gezielt Vereinfachungen als Irreführung verstehen, wenn gleichzeitig die Meinung des Sprechers nicht der ihren entspricht.

Ich bin allerdings der Meinung, dass normale Menschen auch zwischen Erklärungen und Kommentaren durchaus unterscheiden können. Schon, weil die Wahl der Worte eine andere ist (jedenfalls, wenn man, wie ich keine Irreführung im Sinn hat).

Einige der Fachidioten können das offensichtlich nicht. Sie suchen und finden einen Aufhänger in der Vereinfachung und nutzen diese, um mittels Über-Infomation, welche das Thema für normale Menschen völlig unverständlich machen sollen, ihre Meinung durchzuprügeln. (Zerfledern eines Themas in Detailfragen ist eine beliebte Spielart in der Politik, wenn verhindert werden soll, dass es zu einer Änderung des Status Quo kommt.)

Ganz besonders erbärmlich ist es allerdings, dass dafür dann auch eine konzertierte Aktion herhalten muss. Das zeugt noch mehr von einer gravierenden mentalen Schwäche.
 
mattmiksys schrieb:
Klar hat sich auch der 80x86 gemausert, der 680x0 war aber beispielsweise von Anfang an auf Orthogonalität ausgelegt: Viele breite Register mit weitestgehend einheitlichem Befehlssatz. Dem 8086 war schon sein 8-Bit-Ahn 8080 anzusehen, die um lediglich 4 Bit verschobenen Segmentregister waren nichts Halbes und nichts Ganzes, das nächste Limit schon erkennbar (1 MByte).
Das wäre alles Schnee von gestern, wenn der PC als solcher die Bastellösungen (Interrupt-Controller, Centronics-Schnittstelle) nicht in die Serie geschleppt hätte, die ursprünglich mal auf ein paar hunderttausend ausgelegt war.
Ich sehe Apples Entscheidung als den technischen Schritt zurück, um wirtschaftlich mehrere Schritte voran zu kommen. Und profitiere selbst davon, weil ich zweigleisig arbeite...
Das ist doch alles heute so abstrahiert im Prozessor-Frontend dass es nun wirklich nichts mehr ausmacht.

Die neuen PowerPCs machen nichts anderes, da wird auch kein direktes RISC mehr ausgeführt.
 
Coda schrieb:
Das ist doch alles heute so abstrahiert im Prozessor-Frontend dass es nun wirklich nichts mehr ausmacht.

Die neuen PowerPCs machen nichts anderes, da wird auch kein direktes RISC mehr ausgeführt.
Schon klar, aber den Ingenieur muss/sollte es schmerzen, wenn Basteleien zum Standard werden...
 
Zurück
Oben Unten