mattmiksys
Aktives Mitglied
- Dabei seit
- 04.06.2003
- Beiträge
- 2.000
- Reaktionspunkte
- 162
wenn's man eine gewesen wäre...ste^2 schrieb:...die Diskussion ...
Folgen Sie dem Video unten, um zu sehen, wie Sie unsere Website als Icon auf Ihrem Homescreen erstellen.
Anmerkung: This feature may not be available in some browsers.
wenn's man eine gewesen wäre...ste^2 schrieb:...die Diskussion ...
mattmiksys schrieb:wenn's man eine gewesen wäre...
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.
...
"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.
._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.
._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.
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?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
EFI ist kein BIOS-Interface, sondern ein Ersatz dafür. Das solltest du mal verstehen.._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).
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.._ut schrieb:Bei Trollaktionen allerdings nur Verlierer.
Natürlich geht das. Das ist doch kein Kernel-Code.._ut schrieb:Unter Tiger laufen 64-bit-Programme mit 32-bit-GUI, diese Strategie geht beim x86 nicht.
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.._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).
Psycho-Dad schrieb:Besonders werden sie erst du MacOS X.
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 gehtPsycho-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
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
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).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
Ich auch (schon auch ein Wegbereiter zum Mac, oder?)!ste^2 schrieb:...Ich hatte ja auch einen Atari ST
Nein, das mache ich nicht.-Nuke- schrieb:Ja, ist echt nicht schön, was du hier andauernd machst...
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.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...
Nein, darum ging es ursprünglich und dann wurde von anderer Seite das Thema gedreht.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.
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).Und zu dem Rest, wegen 64bit. Dabei kannst du ja nun nicht mitreden, da du die IBM-Dokumente ignorierst.... siehe Post einen über mir...
Das ist doch alles heute so abstrahiert im Prozessor-Frontend dass es nun wirklich nichts mehr ausmacht.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...
Schon klar, aber den Ingenieur muss/sollte es schmerzen, wenn Basteleien zum Standard werden...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.