Archiv verlassen und diese Seite im Standarddesign anzeigen : Frage zur 32-Bit-Adressierungsgeschichte
Senior Sanchez
2008-07-19, 15:32:57
Hallo,
Ich habe da mal eine Frage, die mir gerade etwas Kopfzerbrechen bereitet.
Ein Prozessor der 32-Bit Architektur hat ja in der Regel 32 Adressleitungen (ja, ich weiß, moderne Pentiums haben auch 36 Leitungen). Somit ist der Adressraum, den er adressieren kann 2^32, was etwa 4 Milliarden BIT entsprechen würde. Warum kann er dann aber maximal 4 Milliarden BYTE adressieren? Wieso plötzlich der Übergang von Bit auf Byte? Und hat der 32-Bit Prozessor nicht normalerweise ne Wortbreite von 32 Bit, also 4 Byte, sodass er maximal 4 Milliarden Bit (die Adresse im RAM) * 4 Byte = 16 Milliarden byte adressieren könnte? Oder wird ein RAM immer Byte-Weise adressiert?
Oder wird ein RAM immer Byte-Weise adressiert?
Ja, RAM wird byteweise adressiert.
Tigerchen
2008-07-19, 15:51:30
Hallo,
Ich habe da mal eine Frage, die mir gerade etwas Kopfzerbrechen bereitet.
Ein Prozessor der 32-Bit Architektur hat ja in der Regel 32 Adressleitungen (ja, ich weiß, moderne Pentiums haben auch 36 Leitungen). Somit ist der Adressraum, den er adressieren kann 2^32, was etwa 4 Milliarden BIT entsprechen würde. Warum kann er dann aber maximal 4 Milliarden BYTE adressieren? Wieso plötzlich der Übergang von Bit auf Byte? Und hat der 32-Bit Prozessor nicht normalerweise ne Wortbreite von 32 Bit, also 4 Byte, sodass er maximal 4 Milliarden Bit (die Adresse im RAM) * 4 Byte = 16 Milliarden byte adressieren könnte? Oder wird ein RAM immer Byte-Weise adressiert?
Mit den vorhandenen 32 Bit läßt sich im Binärsystem maximal die Zahl 4 294 967 296 darstellen. Und genau so viele Speicherzellen lassen sich adressieren. So mußt du rechnen.
...
Senior Sanchez
2008-07-19, 15:58:39
Mit den vorhandenen 32 Bit läßt sich im Binärsystem maximal die Zahl 4 294 967 296 darstellen. Und genau so viele Speicherzellen lassen sich adressieren. So mußt du rechnen.
...
Japs, jetzt wars mir klar :)
in C/C++ kann man mindestens auch nur ein Byte ansprechen.
Einen kleineren Variablentyp wie char was 1 Byte groß ist gibts nicht.
Keine Ahnung wie es anderen Sprachen oder gar Assembler aussieht.
Wenn man ein einzelnes Bit auslesen willst muss man ein binäres UND machen
Tigerchen
2008-07-19, 16:30:25
in C/C++ kann man mindestens auch nur ein Byte ansprechen.
Einen kleineren Variablentyp wie char was 1 Byte groß ist gibts nicht.
Keine Ahnung wie es anderen Sprachen oder gar Assembler aussieht.
Wenn man ein einzelnes Bit auslesen willst muss man ein binäres UND machen
Das hat erstmal nichts mit dem Thema Adressraum zu tun.
Wozu man einzelne Bits braucht und wie man sie setzt, löscht, invertiert, rotiert, schiebt oder ausliest ist ein anderes Thema.
[COLOR="#000099"]
Das hat erstmal nichts mit dem Thema Adressraum zu tun.
Nunja der ansprechbare Addressraum eines C/C++ Programms arbeitet eben auch auf Byte Ebene nicht auf Bit ebene
Ein 32bit kompiliertes Programm nutzt ja 32bit Pointer und damit kann man eben 2^32 Byte und eben nicht Bit ansprechen.
Wozu man einzelne Bits braucht und wie man sie setzt, löscht, invertiert, rotiert, schiebt oder ausliest ist ein anderes Thema.
Klar, ich wollt nur sagen das man zumindest in C/C++ auch nur Bytes ansprechen kann und zum auslesen einzelner Bits die CPU ein binäres und machen muss und man das halt nicht direkt machen kann.
Spasstiger
2008-07-19, 16:48:51
Ja, RAM wird byteweise adressiert.
Richtig, und mehr gibts dazu eigentlich auch nicht zu sagen.
/EDIT: Ok, nur damit kein falscher Eindruck entsteht, RAM muss nicht zwangsweise byteweise addressiert werden. Bei 16-Bit-Prozessoren ist es z.B. sinnvoller, wortweise (16 Bit) zu addressieren, um mehr RAM nutzen zu können (128 KiB statt 64 KiB).
Tigerchen
2008-07-19, 18:33:50
Richtig, und mehr gibts dazu eigentlich auch nicht zu sagen.
/EDIT: Ok, nur damit kein falscher Eindruck entsteht, RAM muss nicht zwangsweise byteweise addressiert werden. Bei 16-Bit-Prozessoren ist es z.B. sinnvoller, wortweise (16 Bit) zu addressieren, um mehr RAM nutzen zu können (128 KiB statt 64 KiB).
Es gibt meines Wissens nach keine Byte Adressierung. Ihr seid völlig auf dem falschen Dampfer. Mit 16 Bit lassen sich niemals mehr als 65.536 Speicherzellen ansteuern. Für den 1 MByte Adressraum (20 Bit) des 8086 wurde extra der Krampf mit den Segmentregistern eingeführt. Die waren aber selber auch nur 16 Bit breit und es wurde mittels Segment:Offset eine 20 Bit Adresse generiert.
Heute wird immer 32 Bit Flat adressiert. Damit ist die unsägliche Segmentadressierung im 386 Mode effektiv abgeschaltet.
Ectoplasma
2008-07-20, 09:52:42
Klar, ich wollt nur sagen das man zumindest in C/C++ auch nur Bytes ansprechen kann und zum auslesen einzelner Bits die CPU ein binäres und machen muss und man das halt nicht direkt machen kann.
Das hat mit C++ gar nichts zu tun, dass ist selbst in Assembler so. Ein Byte ist die kleinste Einheit, die direkt adressierbar ist. Danach kommt ein Nibble (4-Bit), welches schon nicht mehr direkt adressierbar ist.
Es gibt meines Wissens nach keine Byte Adressierung.
Es ja auch der Auflösungsbereich einer Adresse in einem 32-Bit System gemeint. Ein Adresse selbst ist in einem 32-Bit System natürlich auch 32-Bit breit. Wobei es bei der Adressauflösung selbst sogar egal ist, welches System man hat, 8-Bit, 16-Bit, 32-Bit, und 64-Bit Systeme haben alle eine Adressauflösung von einem Byte.
es gab jedoch zumindest früher auch andere byte grössen, 6 bit waren stellenweise sehr verbreitet
Hallo,
ich glaube hier wird vergessen das man eine 32Bit Architektur nicht gleichsetzen darf mit einer 32Bit Speicheradressierung. Das auch kann weniger sein. Die CPU rechnet "nur" mit 32Bit.
Ich habe da gerade eine kleine Tabelle von 64Bit CPUs zur Hand. Nennt sich alles 64Bit CPU. Die können mit 64Bit Registern rechnen, aber die Speicheradressierung ist deshalb noch lange nicht 64Bit breit. Siehe virtuelle/phys. Adresse. Den größten Adressraum kann laut der leicht alten Tabelle der Intel Itanium verwalten.
http://img262.imageshack.us/img262/1896/64bitcpus800cm9.jpg
Es ist aber nicht weniger. x86-64-CPUs können heutzutage mindestens 36 bit physikalisch ansprechen und 48 bit virtuell. Die 36 bit sind über PAE auch im 32-Bit-Modus verfügbar.
Hallo,
Du verstehst mich falsch.
Klar ist es weniger wie für den Laien angenommen. Wenn eine 64Bit CPU nur eine 48Bit breite Speicheradressierung hat - zum Bsp.
Genauso kann es bei manchen 32Bit CPUs sein. Eben keine volle 32Bit Speicheradressierung.
Und wieso spielt das dann hier eine so große Rolle? Den Zusammenhang versteh ich nicht.
BlackBirdSR
2008-07-22, 00:08:16
Hallo,
Du verstehst mich falsch.
Klar ist es weniger wie für den Laien angenommen. Wenn eine 64Bit CPU nur eine 48Bit breite Speicheradressierung hat - zum Bsp.
Genauso kann es bei manchen 32Bit CPUs sein. Eben keine volle 32Bit Speicheradressierung.
Das ist eine Designentscheidung. Warum sollte man sich die Kosten machen, volle 64Bit physikalisch zu adressieren, wenn keine CPU die damit verkauft wird, jemals in solch eine Situation kommt?
Alle bis dahin verfügbaren K8 wären schon länst nicht mehr funktionsfähig und ausgemustert ;)
AMD hält sich die Option offen die Adresserierung für AMD64 bei Bedarf ohne weiteres auf 52/64 und später 64/64 zu erweitern.
Ansonsten stimme ich Coda zu. Den Zusammenhang verstehe ich nicht. Zudem hat "mit 32-Bit Rechnen" nicht viel damit zu tun. Es gibt genug Datentypen, Register, Werte und FUs die mit weit mehr als 32-Bit Rechnen, und das schon seit sehr vielen Jahren in sehr vielen 32-Bit CPUs.
Haarmann
2008-07-22, 10:31:51
Senior Sanchez
Weil diese Architektur von Intel stammt wohl... und schon zu Anfang mit 32 Bit Adressen nur 1 MB gleichzeitig nutzen konnte...
Wäre die Konvention ergangen, dass grössere Variablen immer ausgerichtet im Speicher stehen müssen und in Registern wäre jedes Byte einzeln anspechbar, dann könnte man problemlos auch mit weniger "Beinen" und kürzeren Zeigern auskommen. Aber dann wärs nicht Intel ;).
Tigerchen
Wenn dem so wäre, würden viele Leute wohl noch ASM auf x86 nutzen...
Leider ist die verblödete 8086 Segment Offset Variante nur einer genausoverblödeten Pagevariante gewichen. Deswegen konnte Windows auch immer so gut auslagern auf die Platte ;).
Auf den flachen Adressraum, welcher sowas von schön und einfach wär, waren wir wohl noch ne Weile...
BlackBirdSR
Machte Motorola mit dem 68k ja auch... 16 MB Adressraum, aber 32 Bit breite Adressregister. Bleibt auch bei Erweiterung eben kompatibel.
[...]einer genausoverblödeten Pagevariante gewichen. [...]
Auf den flachen Adressraum, welcher sowas von schön und einfach wär, waren wir wohl noch ne Weile...
Wie implementiert man ohne Pages multiprocessing mit segregiertem Speicher? Was hast du gegen Pages?
wurde das paging eigentlich in der form in den 386 und später eingebaut in der hoffnung dass irgendjemand da draus tatsächlich mal ein (für die anwendung transparentes) paging/swapping einbaut oder hat man erst später gemerkt "hey bei einem speicherfehler kann man ja auch anstatt das programm zu beenden einfach die gewünschte speicherseite von der platte laden und anschliessens weitermachen als wäre nix geschehen"
Haarmann
2008-07-23, 11:52:00
Trap
Ein Amiga ist ein Multiprozessorsystem (es sind nicht identische Prozessoren, aber mehrere) - ich hätte nie Pages oder Segmente gebraucht um mehrere der vorhandenen Prozessoren nutzen zu können.
Einzig den Speicherschutz vor marodierenden Anwendungen hat man natürlich vermisst...
Und bleibe mir mit Segmenten fern - das ist wohl der grösste Mist, der je erfunden wurde. Das funktioniert nur so lange gut, wie Dein grösstes "Datenfeld" in ein Segment passt...
Wenn dem so wäre, würden viele Leute wohl noch ASM auf x86 nutzen...
Leider ist die verblödete 8086 Segment Offset Variante nur einer genausoverblödeten Pagevariante gewichen. Deswegen konnte Windows auch immer so gut auslagern auf die Platte ;).
Auf den flachen Adressraum, welcher sowas von schön und einfach wär, waren wir wohl noch ne Weile...
Bitte was? Jedes 32-Bit-Programm hat einen flachen 32-Bit-Adressraum in jedem OS das für i386 jemals verwirklicht wurde. Von den Pages sieht man doch überhaupt nichts.
Und jede Architektur mit einer MMU hat natürlich Pages. Sonst würde virtueller Adressraum überhaupt nicht funktionieren.
Was manche hier mal wieder für haarsträubendes Zeug ablassen. Man könnte auch sagen "Wenn man keine..." aber ich lass es.
wurde das paging eigentlich in der form in den 386 und später eingebaut in der hoffnung dass irgendjemand da draus tatsächlich mal ein (für die anwendung transparentes) paging/swapping einbaut oder hat man erst später gemerkt "hey bei einem speicherfehler kann man ja auch anstatt das programm zu beenden einfach die gewünschte speicherseite von der platte laden und anschliessens weitermachen als wäre nix geschehen"
Das war alles so gewollt. Der protected mode wurde sehr gut durchdacht und geht sogar noch weiter als ihn die Betriebssysteme je ausgenützt haben. x86-64 hat sogar wieder Dinge rausgenommen die nie verwendet wurden.
Haarmann
2008-07-23, 12:11:38
Coda
Als ob mich das Proggen unter einem OS interessiert hätte...
ASM ist nicht gerade die bekannteste "Sprache" um ne API aufzurufen...
Wie spassig es war, wenn man gegen den Amiga vergleicht, ne VGA Karte direkt anzusprechen (der 320*200 Modus gilt hier nicht), kannst Dir bestimmt vorstellen.
Coda
Als ob mich das Proggen unter einem OS interessiert hätte...
ASM ist nicht gerade die bekannteste "Sprache" um ne API aufzurufen...
Wie spassig es war, wenn man gegen den Amiga vergleicht, ne VGA Karte direkt anzusprechen (der 320*200 Modus gilt hier nicht), kannst Dir bestimmt vorstellen.
Wo ist da denn der Zusammenhang? Du hast was gelabert von Zitat "nur einer genausoverblödeten Pagevariante gewichen" und genau das stört mich weil JEDE ARCHITEKTUR das so macht. Und das auch überhaupt nicht dazu führt dass man keinen flachen Adressraum hat aus Applikationssicht. Ja auch wenn man "ASM" verwendet.
Was für eine unglaubliche Grütze. Dass der Real-Mode mit seinen Segementen ein Dreck war weiß ich genauso gut. So alt bin ich dann auch schon das ich das noch verwenden durfte.
Dass der Real-Mode mit seinen Segementen ein Dreck war weiß ich genauso gut. So alt bin ich dann auch schon das ich das noch verwenden durfte.
Ist es vorstellbar (bzw. überhaupt machbar), dass es mal x86 CPUs geben wird, die auch beim Initialisieren direkt als 32Bit CPU oder gar 64Bit CPU erkannt werden?
Sicher. Aber was würde das nützen? Man kann auch durch ein kurzes Schnipsel Firmware-Code sofort in den Protected Mode.
Grestorn
2008-07-23, 12:58:38
Ein Amiga ist ein Multiprozessorsystem (es sind nicht identische Prozessoren, aber mehrere) - ich hätte nie Pages oder Segmente gebraucht um mehrere der vorhandenen Prozessoren nutzen zu können.
Einzig den Speicherschutz vor marodierenden Anwendungen hat man natürlich vermisst...
Und bleibe mir mit Segmenten fern - das ist wohl der grösste Mist, der je erfunden wurde. Das funktioniert nur so lange gut, wie Dein grösstes "Datenfeld" in ein Segment passt...
Der Prozessor des Amigas, der 68000, war von der internen Adressierung her schon immer ein 32bit Prozessor (auch wenn je nach Modell nicht alle Adressleitungen nach außen verfügbar sind). Deswegen gab es beim Amiga nie Adressierungsprobleme. Die wären dort auch erst bei mehr als 2 GB Hauptspeicher aufgetreten, was aber zu Lebzeiten des 68000er Amigas ja nie ein Thema war.
Ganz anders schaut es übrigens bei der generellen Adressierung von Daten aus. Damit die Backups von Diavolo Backup größer als 2 GB werden konnten (und trotzdem jedes File im Backup direkt adressiert werden konnte) musste ich damals selbst eine Art Segmentierung in Diavolo Backup implementieren. Den 64bit Integer gibt es nun mal nicht direkt auf dem 68000er.
Ectoplasma
2008-07-23, 13:00:33
Senior Sanchez
Weil diese Architektur von Intel stammt wohl... und schon zu Anfang mit 32 Bit Adressen nur 1 MB gleichzeitig nutzen konnte...
Wäre die Konvention ergangen, dass grössere Variablen immer ausgerichtet im Speicher stehen müssen und in Registern wäre jedes Byte einzeln anspechbar, dann könnte man problemlos auch mit weniger "Beinen" und kürzeren Zeigern auskommen. Aber dann wärs nicht Intel ;).
Tigerchen
Wenn dem so wäre, würden viele Leute wohl noch ASM auf x86 nutzen...
Leider ist die verblödete 8086 Segment Offset Variante nur einer genausoverblödeten Pagevariante gewichen. Deswegen konnte Windows auch immer so gut auslagern auf die Platte ;).
Auf den flachen Adressraum, welcher sowas von schön und einfach wär, waren wir wohl noch ne Weile...
BlackBirdSR
Machte Motorola mit dem 68k ja auch... 16 MB Adressraum, aber 32 Bit breite Adressregister. Bleibt auch bei Erweiterung eben kompatibel.
Warst du vielleicht 15 Jahre lang auf einer einsamen Insel? Abgesehen davon ist es so, dass der Adressraum seit einem i386, 32-Bit Flat ist. Die Pages sind transparent für die Anwendung. Es gibt eigentlich keine CPU, die das nicht so macht. Das hat mit Intel gar nichts zu tun.
Man setz dich hin und ließ ein Buch, aber gib nicht so ein unsinniges Halbwissen von dir.
Haarmann
2008-07-23, 13:25:02
Grestorn
Eben... und wer von dieser Richtung her kommt, der wird x86 nicht lieben...
Segmentierung hat immer so, seit 8086, den Klang, dass man die gleiche Scheisse auf 4096 Arten ansprechen kann ;).
Und 32 Bit Adressen warens damit auch... nur einfach nicht ganz effizient genutzt...
Coda
68030 hats nicht gleich gelöst... der 68020 auch nicht... das lag, wie Grestorn richtig festgestellt hat, schon an der Architektur. Ich kam von Dieser...
Mich betraf es damals direkt so, dass ich aus DOS, also Real Mode, resp. Pseudorealmode, hätte umschalten müssen. Und da vergeht Dir die Laune auf Intel, und PC AT nebenher, gewaltig!
Um etwas "Klugscheisser" zu spielen... welchen Protected Mode meinst denn? Intel kennt da nicht nur einen...
Ectoplasma
Müsste nachsehen, wie das Buch genau heisst ;). Ich las also ein Buch...
Es ist etwa auch 15 oder mehr Jahre alt ... gut geschätzt.
Nein, auf einer Insel lag ich in der Zeit leider nicht mit den Hula Mädels... aber definitiv war mein Bedürfnis nach Intel ASM gestillt... die PC AT Architektur hatte natürlich auch einen gewissen Anteil an der Sache... Marx ist Theorie und Murks die Praxis.
Den Erfinder von der Real Mode Adressierung seitens Intel sollte man Teeren und Federn!
Es gibt Leute, denen ists Wurst, wo der Speicher ist... die wollten nur wissen, wieviel liegt wo und nutzten dann, was da war oder gaben nen Fehler raus. Auslagern auf Platte kann ich selber...
Was interessiert denn heute noch das Real-Mode-Zeug? Das ist doch völlig irrelevant. Und du solltest mal lernen ordentlich zu quoten. Das Zeug kann man doch nicht lesen.
Welcher Protected Mode (24, 32 oder 64 bit) ist auch völlig irrelevant. Vor allem der vom 286. Alle bieten ein flaches Speichermodell.
Hör endlich auf Grütze von dir zu geben. Es gibt keine komische Segment-Offset-Adressierung mehr auf x86 in einer 32- oder 64-Bit-Umgebung.
Haarmann
2008-07-23, 13:34:49
Coda
Leider "bootet" auch der C2D oder der K10 nach wie vor wie ein 8086...
Wer ohne OS leben will, der wird ums Umschalten nicht rumkommen...
Du redest beständig vom OS und ich rede von ohne OS.
(Ich liess die exotischen PS/2 Systeme mal Aussen vor)
Leider "bootet" auch der C2D oder der K10 nach wie vor wie ein 8086...
Wer ohne OS leben will, der wird ums Umschalten nicht rumkommen...
Wer ohne OS leben will für den ist das mit Abstand das kleinste Problem. Das ist nichtmal 1KiB Code.
Du redest beständig vom OS und ich rede von ohne OS.
Was für eine Relevanz hat das? Wer programmiert heute noch irgendwas ohne OS?
und ich rede von ohne OS.
das ist wohl der grund warum dein gerede keinen interessiert.
Haarmann
2008-07-23, 14:06:59
Coda
Auf das KB ASM Code bin ich gespannt... posten bitte
Als der 386 rauskam gabs nunmal nicht wirklich viele 32 Bit OS -> Du musstest ohne OS auskommen. Und Heute proggt wohl keiner mehr freiwillig ASM... also unter Windows oder Linux zB.
Gast
Ich hab immer gesagt, von was ich ausging. Nur weil etwas ne Nische darstellt, sollte man sie nicht negieren. Betriebsysteme werden auch Heute noch geproggt - oder?
Als der 386 rauskam gabs nunmal nicht wirklich viele 32 Bit OS -> Du musstest ohne OS auskommen. Und Heute proggt wohl keiner mehr freiwillig ASM... also unter Windows oder Linux zB.
Und wieder einmal zeigt sich die enorme Relevanz für den heutigen Zustand. Und es gibt noch genügend Leute die Assembler programmieren. Nur sehr selten ganze Programme.
Ich hab immer gesagt, von was ich ausging. Nur weil etwas ne Nische darstellt, sollte man sie nicht negieren. Betriebsysteme werden auch Heute noch geproggt - oder?
Oh yeah. Wir sollten x86 wirklich wirklich ganz ganz dringend von dem schlimmen Real-Mode befreien dass die unglaublichen Horden an OS-Programmierern endlich nicht mehr im Schlaf weinen müssen, weil sie in den Megabytes an Sourcecode ein paar Zeilen für die x86-Protected-Mode-Initialisierung programmieren mussten die sich nie ändern.
Haarmann
2008-07-23, 14:42:33
Coda
Ich dachte natürlich an ganze Programme... nicht nur an Optimierungen. Ich hätte das genauer ausdrücken sollen. Ist aus dem Kontext wirklich nur erahnbar.
Bevor Du in den Jokermodus wechselst... das KB Code fehlt... danach darfst Witze machen. Keine Includes und keine "durch die Blume" aufgerufene 16 Bit Ints ausm ROM nebenher.
Können wir vielleicht langsam wieder in die Gegenwart zurückkehren?
del_4901
2008-07-23, 15:15:55
Coda
Auf das KB ASM Code bin ich gespannt... posten bitte
;;; Ein kleines Beispiel, wie man in den 32-Bit Protected Mode wechselt
;;; Bei Fragen kann man sich einfach an die ICQ-Nummer 338-417-614 wenden.
[BITS 16]
org 0x0000 ; Addiert zu allen Offsetes die Start-Adresse dieses Codes
cli ; Interrupts ausschalten
lgdt [gdtr] ; GDT Pointer laden
mov eax,cr0 ; In PMode wechseln, indem das niedrigste
or al,1 ; Steuerungsbit von cr0 geändert wird
mov cr0,eax ; muss über Umweg über ein anderes Register gemacht werden
jmp codesel:PMode ; FarJump zu einer 32-Bit PMode Funktion
[BITS 32]
PMode:
mov ax,datasel ; Segmentregister laden
mov ds,ax
mov ss,ax
mov esp,0x90000 ; Stack aufsetzen
jmp $ ; Endlosschleife, wird durch weiteren Code ersetzt
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; == GDT == ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
gdtr: ; Desktiptortabelle
dw gdt_end-gdt-1 ; Limit
dd gdt ; Basisadresse
gdt:
dd 0,0 ; Null-Deskriptor
codesel equ $-gdt
dw 0xFFFF ; Segmentgrösse 0..15
dw 0x0000 ; Segmentadresse 0..15
db 0x00 ; Segmentadresse 16..23
db 0x9A ; Zugriffsberechtigung und Typ
db 0xCF ; Zusatzinformationen und Segmentgrösse 16...19
db 0x00 ; Segmentadresse 24..31
datasel equ $-gdt
dw 0xFFFF ; Segmentgrösse 0..15
dw 0x0000 ; Segmentadresse 0..15
db 0x00 ; Segmentadresse 16..23
db 0x92 ; Zugriffsberechtigung und Typ
db 0xCF ; Zusatzinformationen und Segmentgrösse 16...19
db 0x00 ; Segmentadresse 24..31
gdt_end:
Naja. A20 sollte man evtl. noch aktivieren, aber im wesentlichen ist es das. Wer's nicht glaubt soll sich die setup.S von nem älteren Linux-Kernel anschauen.
Haarmann
2008-07-23, 15:29:14
Coda
Da sind wir doch die ganze Zeit... 32 Bit ist allerdings bereits auf dem absteigenden Ast. Und wie man das Wort "Geschichte" im Titel deuten will... lasse ich auch offen.
Dass sich hier Intel von anderen 32 Bit Ansätzen unterscheidet, wirst Du wohl kaum bestreiten wollen.
Man könnte zB auch mit dem Zilog Z80000 vergleichen. Auch der Chip ist eine Evolution aus einem älteren Chip.
Bei S3 ist zwar Dein RAMInhalt noch da, aber Deine CPU kanns nicht ansprechen... sie spielt leider immer 8086, wenn sie aufwacht.
Ganz besonders witzig wirds ja erst, wenn man noch die 64 Bit Erweiterung dazu nimmt. Dich kümmert das zwar nicht, aber trotzdem gehörts eben in dies Umfeld rein.
Meinst Du das?
http://tldp.org/HOWTO/Linux-i386-Boot-Code-HOWTO/setup.html
AlphaTier
Das werde ich noch analysieren - wenns recht ist, aber Hut ab, dass Du sowas lieferst und nicht einfach laverst.
Schade habe ich keinen uralten 386er rumliegen, der noch mit DOS rum"rennt".
Da sind wir doch die ganze Zeit... 32 Bit ist allerdings bereits auf dem absteigenden Ast.
So what? Im 64-Bit-Modus gibt's auch nur flachen Speicher.
Und wie man das Wort "Geschichte" im Titel deuten will... lasse ich auch offen.
Da gibt's nichts zu deuten. "Geschichte" in dieser Verwendung heißt einfach "Sache".
Dass sich hier Intel von anderen 32 Bit Ansätzen unterscheidet, wirst Du wohl kaum bestreiten wollen.
Doch das tue ich. Auch PowerPC, Sparc und Itanium haben Pages und eine MMU. Es gibt eben keinen Unterschied. Das erzähl ich dir aber schon Stunden lang.
Bei S3 ist zwar Dein RAMInhalt noch da, aber Deine CPU kanns nicht ansprechen... sie spielt leider immer 8086, wenn sie aufwacht.
Dann geht man halt wieder in den protected mode. Was ein Problem.
Ganz besonders witzig wirds ja erst, wenn man noch die 64 Bit Erweiterung dazu nimmt. Dich kümmert das zwar nicht, aber trotzdem gehörts eben in dies Umfeld rein.
Was soll daran "witzig" sein?
Ectoplasma
2008-07-23, 16:26:49
Ich verstehe dich auch nicht so ganz Haarmann, was ist denn dein Motiv, das jetzt hervorzukramen? Wer will ohne OS irgendetwas machen? Ok, vielleicht ein Atomkraftwerk steuern ... ? Jetzt mal echt, wieso ziehst du solche Dinge aus dem Dunkel des längst vergessenen, wieder hinauf ans Tageslicht?
Grestorn
2008-07-23, 18:27:29
AlphaTier
Das werde ich noch analysieren - wenns recht ist, aber Hut ab, dass Du sowas lieferst und nicht einfach laverst.
Ich will nicht AlphaTiers Beitrag schmälern, aber da hat er's her: http://lowlevel.brainsware.org/wiki/index.php/Umschalten_in_Protected_Mode
Das hättest Du auch in 5 Sekunden im Google gefunden, wenn Du wirklich Interesse daran gehabt hättest.
Haarmann
2008-07-23, 18:58:49
Coda
Flach und ausgerichtet?
Darum ging die Frage ja hautpsächlich... wieso man nicht von einer ausgerichteten Datenmenge ausgeht, welche tatsächlich die letzten 2 Bits einsparte (bei 32 Bit) und damit bei 32 Leitungen nicht 4GB, sondern 16GB ermöglichte. Die Geschichte geht eigentlich also um was ganz Anderes...
Wobei wir ev beim Thema flach auch mal klären sollten, ob wir logisch oder physisch meinen. Ich bin immer für Letzteres.
Es sollte Dir auch nicht neu sein, dass ein 32 Bit Wert, der nicht korrekt ausgerichtet ist, nur in 2 Zugriffen eingelesen werden kann. Gäbs keinen "Real Mode" wär solcher Murks nie zugelassen worden, womit die letzten 2 Bits, für 32 Bit, schlicht überflüssig würden oder zur Erweiterung des Adressbereichs genutzt werden könnten.
Wir wissen ja, dass das der Inhaltvom ROM immer im ersten MB stehen muss...
Setzen wir den Fall, dass hier 4GB RAM irgendwo rumliegen. An welchen "Beinen" liegt das RAM nun physisch?
Auch glaube nicht, dass ein Itanium eine 32 Bit CPU ist...
Dafür könnte ein PPC auch im "64 Bit Modus" 32 Bit Code direkt ausführen...
Durchaus nicht so einfach ... man muss ja vorm "Schlafengehen" so einiges ins erste MB "schieben". Wieviel Mühe gerade das Auswachen aus diesem Zustand macht, haben sicher auch einige hier schon bemerkt...
Gewisse direkte Umschaltvorgänge sind bei x86 nicht möglich...
Ectoplasma
Der Threadersteller hatte imho auch ganz andere Gedanken... durchaus sinnvolle, wenn ich das bemerken darf.
Ich erkläre weiter oben in diesem Post genauer, wie ich den Titel interpretiere.
Und es ist keineswegs logisch, dass 32 Bit Prozessoren 32 Beinchen brauchen für 4 GB... 30 tätens auch.
Grestorn
Bist Du sicher, dass der Rechner, wenn Du einfach so umschaltest, beim nächsten Timerimpuls noch läuft?
Grestorn
2008-07-23, 20:07:04
Grestorn
Bist Du sicher, dass der Rechner, wenn Du einfach so umschaltest, beim nächsten Timerimpuls noch läuft?
Grundsätzlich bin ich da überhaupt nicht sicher, da ich mich da noch nie mit auseinandergesetzt habe.
Allerdings werden die Interrupts erst deaktiviert (CLI) und natürlich muss dafür gesorgt werden, dass der (A)PIC nach der Umschaltung erst mal neu programmiert wird.
Haarmann
2008-07-23, 20:17:16
Grestorn
Das würde eine Umschaltung wohl etwas verkomplizieren und länger machen ;).
Man kann auch durch ein kurzes Schnipsel Firmware-Code sofort in den Protected Mode.
Um mal einen unqualifizierten Kommentar abzulassen. Lassen wir doch bei den Autos den Anlasser weg, kurzes Drehen an der Kurbel tut es doch auch...
BlackBirdSR
2008-07-23, 20:56:11
Um mal einen unqualifizierten Kommentar abzulassen. Lassen wir doch bei den Autos den Anlasser weg, kurzes Drehen an der Kurbel tut es doch auch...
Was alle Stop und Go Ambitionen der Hersteller zunichte machen würde....
Im Falle der x86 verliert man eben die Abwärtskompatibilität. Wir haben diese Hemmschuhe nunmal. Sie sind nötig und vielleicht nicht schön. Aber sie sind auch kein großes Problem. Also warum aufregen?
Was alle Stop und Go Ambitionen der Hersteller zunichte machen würde....
wird das Stop and Go beim Rechner nicht auch dadurch erschwert, dass wenn der Rechner in den Ruhezustand fährt beim Aufwecken auch erst wieder bis in den 64 Bit Modus hochswitchen muss?
Im Falle der x86 verliert man eben die Abwärtskompatibilität. Wir haben diese Hemmschuhe nunmal. Sie sind nötig und vielleicht nicht schön.
mal so gefragt, wieiviele Millionen "X86" CPUs gibt es die keine 5 Jahre alt sind und wieviele dutzend (paar) Anwendungen gibt es die noch die uralten Relikte benötigen? Vermutlich liegt da ein ziemliches Missverhältnis vor.
Anders gefragt, welche Vorteile hat der Programmierer der heute ein Programm schreibt von diesen Relikten? Welche Vorteile hat der Anwender der sich nen neuen Vista PC gekauft hat?
Aber sie sind auch kein großes Problem. Also warum aufregen?
wo is das grosse Problem die Anlasskurbel in den Innenraum zu verlegen? ;)
Flach und ausgerichtet?
Darum ging die Frage ja hautpsächlich... wieso man nicht von einer ausgerichteten Datenmenge ausgeht, welche tatsächlich die letzten 2 Bits einsparte (bei 32 Bit) und damit bei 32 Leitungen nicht 4GB, sondern 16GB ermöglichte. Die Geschichte geht eigentlich also um was ganz Anderes...
Weil man Bytes adressieren will weil sonst allein die ganzen Programme nicht mehr kompatibel sind. Ich kenne auch keine Architektur die nicht ein Byte als kleinste Einheit hätte.
Es sollte Dir auch nicht neu sein, dass ein 32 Bit Wert, der nicht korrekt ausgerichtet ist, nur in 2 Zugriffen eingelesen werden kann.
Das ist völlig hardwarespezifisch. Nehalem kann das schneller.
Anders gefragt, welche Vorteile hat der Programmierer der heute ein Programm schreibt von diesen Relikten? Welche Vorteile hat der Anwender der sich nen neuen Vista PC gekauft hat?
Gegenfrage: Wen interessieren die paar Transistoren die nötig sind um den Real Mode weiterhin anzubieten?
wird das Stop and Go beim Rechner nicht auch dadurch erschwert, dass wenn der Rechner in den Ruhezustand fährt beim Aufwecken auch erst wieder bis in den 64 Bit Modus hochswitchen muss?
Das geht schneller als das Licht von deiner Zimmerlampe zu deinen Augen braucht.
Abraxus
2008-07-23, 23:26:10
Das geht schneller als das Licht von deiner Zimmerlampe zu deinen Augen braucht.
DAS halte ich noch für ein Gerücht ;)
BlackBirdSR
2008-07-23, 23:40:31
mal so gefragt, wieiviele Millionen "X86" CPUs gibt es die keine 5 Jahre alt sind und wieviele dutzend (paar) Anwendungen gibt es die noch die uralten Relikte benötigen? Vermutlich liegt da ein ziemliches Missverhältnis vor.
;)
Anders gefragt: Wieviele Systeme gäbe es, die nicht mehr funktionieren, wenn du das jetzt sofort im nächsten x64 Prozessor von Intel oder AMD änderst?
Alle, denn dann brauchst du ersteinmal ein neues Bios.
Klar braucht die Relikte keiner mehr für Software. Wer nutzt schon sein Dos basiertes CNC-Programm auf einem Nehalem? Aber der Aufwand diese Sachen zu entfernen und umzustellen ist größer als es mitzuschleppen und die wenigen Extraschrtitte auszuführen.
Klar bekommen wir ein neues Bios-System. Und dann kann man es auch irgendwann über Board werfen. Aber bis dahin will den Schritt niemand gehen, und es tut auch niemandem weh.
Und mal ganz ehrlich: Wenn wir jetzt alle groß anfangen zu diskutieren, warum dieser Ballast nicht abgeworfen wird, und wie wenig Probleme er eigentlich bereitet - dann wir rein aus fairness auch über so einige andere Dinge sprechen, denn x86 ist voll davon. Also was soll als nächstes raus?
Übertakten über Software (nichts über das Bios) und Ruhemodus scheint nicht zu funktonieren, da der "Übertaktungswert" in einem Speicherbereich geschrieben wird, den der Real-Mode, in dem sich die CPU beim Aufwachen sich erstmal nach dem Aufwachen befindet, nicht kennt. So scheint es zumindest bei einem Software-Übertaktungstool auf dem MacPro zu laufen, denn dort gibt es AFAIK genau dieses Problem.
Das werde ich noch analysieren - wenns recht ist, aber Hut ab, dass Du sowas lieferst und nicht einfach laverst.
Du kannst mich echt mal. Ich "laver" hier überhaupt nicht, ich weiß sehr genau von was ich rede. Absolute Frechheit.
DAS halte ich noch für ein Gerücht ;)
Bei 3m Abstand und 3Ghz wären das immerhin schon 30 Takte. Ich weiß nicht wie lange die Instructions brauchen, aber so unmöglich ist es gar nicht.
Übertakten über Software (nichts über das Bios) und Ruhemodus scheint nicht zu funktonieren, da der "Übertaktungswert" in einem Speicherbereich geschrieben wird, den der Real-Mode, in dem sich die CPU beim Aufwachen sich erstmal nach dem Aufwachen befindet, nicht kennt. So scheint es zumindest bei einem Software-Übertaktungstool auf dem MacPro zu laufen, denn dort gibt es AFAIK genau dieses Problem.
Läuft das Ding denn als Kerneltreiber? Sonst ergibt das keinen Sinn. Und selbst dann wird sicher kein Treiber laufen bevor auf Protected Mode umgeschalten wurde.
Imho hat das gar nichts damit zu tun sondern schlicht und einfach mit dem Fakt dass die CPU wieder auf Defaultfrequenz aufwacht. Das hat aber rein gar nichts mit x86 zu tun.
Haarmann
2008-07-24, 08:24:29
BlackBirdSR
Die klassische FPU mit ihrem "wundervollen" Stack ist auch verstorben... der 8087 ist also in Pension geschickt worden - fehlt nur noch der 8086. Die Mehrzahl der alten DOS Krücken läuft ohnehin nicht mehr direkt...
Wenn schon alle von EFI reden... dann mache man Nägel mit Köpfen und schneide zB das Gate A20 mal ab (Exemplarisch für nen alten Zopf).
Coda
Selbst der uralte 8086 kann doch keine 16-Bit Werte auf ungeraden Adressen lesen, er umgeht das mit 2 Zugriffen, damit sind wir wieder beim Kernthema. Der unterste Pin ist damit faktisch nutzlos und hätte anders genutzt werden können.
Auch Dein Nehalem wird, wenn der Wert unausgerichtet ist für ihn, diesen wohl nur in 2 Cachelines unterbringen können.
Das Problem der Bytezugriffe auf eine beliebige Speicherstelle lässt sich auch durch die Register beheben. Aber genau hier patzt zB der 386 - damit ist er jedoch nicht alleine.
Das ist ein gutes Berner Sprichtwort... liefern nicht lavern. Kann man auch einfach als "Lass Taten sprechen" übersetzen, da Taten ja mehr denn Worte sagen.
Gegenfrage: Wen interessieren die paar Transistoren die nötig sind um den Real Mode weiterhin anzubieten?
okay, bauen wir also wieder zur Zierde Vergaser in alle Autos ein und den guten alten Luftschlauch legen wir (unaufgepumpt) noch mit in den Reifen rein?!?
Ich muss lange nachdenken um noch andere Bereiche zu finden wo jahrzehnte alte Relikte noch mitgeschleppt werden. Zumeist wird so was sehr schnell rausoptimiert.
Die Menschheit muss es endlich kapieren, mit Energie und Resourcen muss man sparsam umgehen. Dazu gehören auch effiziente Computer aka CPUs und Software. Weniger geätzes Silizium spart Energie. Ein OS das nur halb so lange auf der Festplatte rumrödelt spart auch Energie, etc usw pp. Kleinvieh macht auch Mist und bei Abermillionen Computern ist das in der Summe auch sehr viel Mist.
dann wir rein aus fairness auch über so einige andere Dinge sprechen, denn x86 ist voll davon. Also was soll als nächstes raus?
wieso Fairness? Du redest ja selber von ner Schritt für Schritt Altlastensanierung. Werden wir erstmal den A20 und den 8 Bit los, dann räumen wir den Rest auf. Es kommen schon alle zu ihrem Recht, keine Sorge ;)
wieso Fairness? Du redest ja selber von ner Schritt für Schritt Altlastensanierung. Werden wir erstmal den A20 und den 8 Bit los, dann räumen wir den Rest auf. Es kommen schon alle zu ihrem Recht, keine Sorge ;)
Dann kann man eigentlich direkt auf eine moderne und effizientere Architektur wie PowerPC wechseln (Power6 kann AFAIK ähnlich Rosetta auch x86 Code ausführen). Dummerweise ist Apple genau davon hin zu x86 gewechselt :ugly: IMHO aber aus anderen Gründen, als technische...
Haarmann
2008-07-24, 19:03:49
No.3
Ich hätte irgendwie Lust den alten CPM Emu für DOS und 8080 hochzuladen... dann kann man ja Testen, ob auch ein C2D noch 8080 kompatibel ist ;).
Vielleicht erklärt mir dann irgendwer auch noch, dass dies sinnvoll sei...
okay, bauen wir also wieder zur Zierde Vergaser in alle Autos ein und den guten alten Luftschlauch legen wir (unaufgepumpt) noch mit in den Reifen rein?!?
Ich muss lange nachdenken um noch andere Bereiche zu finden wo jahrzehnte alte Relikte noch mitgeschleppt werden. Zumeist wird so was sehr schnell rausoptimiert.
Der Vergleich hinkt gewaltig. Die Transistormenge ist wirklich gering im Vergleich zu dem was ein Core 2 z.B. für einen Aufwand treibt um Parallelität im Code auszunützen.
wieso Fairness? Du redest ja selber von ner Schritt für Schritt Altlastensanierung. Werden wir erstmal den A20 und den 8 Bit los, dann räumen wir den Rest auf. Es kommen schon alle zu ihrem Recht, keine Sorge ;)
A20 ist noch viel harmloser. Das ist bloß ein AND auf der 20. Adressleitung.
Dann kann man eigentlich direkt auf eine moderne und effizientere Architektur wie PowerPC wechseln (Power6 kann AFAIK ähnlich Rosetta auch x86 Code ausführen). Dummerweise ist Apple genau davon hin zu x86 gewechselt :ugly: IMHO aber aus anderen Gründen, als technische...
Das PowerPC "effizienter" wäre als x86-64 halte ich immer noch für nicht haltbar. Die Code-Density ist z.B. immer noch besser bei x86. Der Vorteil - falls er überhaupt vorhanden ist - ist einfach viel zu gering.
Es stört mich wenn x86 immer so dargestellt wird als wäre es die größte Bremse am Rad die man sich vorstellen kann. Das stimmt einfach nicht. Und schon gar nicht in der 64-Bit-Ausprägung.
Natürlich ist PowerPC effizienter. Wo sind denn bitte die x86-CPUs, die z.B. in Handys passen? ;)
Abraxus
2008-07-24, 20:44:50
Natürlich ist PowerPC effizienter. Wo sind denn bitte die x86-CPUs, die z.B. in Handys passen? ;)
In welchem Handy ist denn ein PPC verbaut?
Das ist ARM und kein PowerPC. Außerdem sind das In-Order-Architekturen. Andere Baustelle.
Wenn man nicht dekodieren muss ist RISC sicher im Vorteil.
Also bei Freescale gibt SoCs auf PowerPC basierend, inkl. GPU, die nur 2 Watt verbrauchen. Ebenso gibt es dort schon einen 8 Core.
- Ein PWRficient hat einen halben Chipsatz intus (wenn ich es richtig in Erinnerung habe sogar zweimal 10GB Lan) und verbraucht dennoch weniger als ein Penryn, bei vermutlich Leistung in ähnlichen Regionen, obwohl P.A. Semi nicht solche hochwertigen Fertigungsmöglichkeiten wie Intel hat.
- Performance/Watt -> Green500: http://www.green500.org/lists/2008/06/ranks1-100.php
- 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.
Quelle: Seite 3 -> http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/AB70A3470F9CC0E287256ECC006D6A54/$file/970-software.pdf
- Ein x86 kann nach dem Aufwachen auch erstmal keinen EFI-Code ausführen, da EFI Code für 80386 verwendet.
- Es gilt wie immer: Anschalten/Aufwachen 8086 (16bit, Real Mode), Initialisieren verschiedener Erweiterungen erst 80286 (Protected Mode, 16 bit), dann 80386 (32bit), dann 80386 mit PAE-Adresserweiterung und schliesslich 64bit-x86-Prozessor.
- effizient :ugly: Jon Stokes: "MDR estimates that close to 40 percent of the P6's transistor budget is spent on x86 legacy support."
http://books.google.com/books?id=Q1zSIarI8xoC&pg=PA107&lpg=PA107&dq=that+close+to+40+percent+of+the+P6's+transistor+budget+ist+spend+on+x86+legac y+support.%22&source=web&ots=qp_EJMdUwr&sig=v25YEUXqIwnBUoVoLPxXmPqk1k4&hl=de&sa=X&oi=book_result&resnum=2&ct=result
- Ein PWRficient hat einen halben Chipsatz intus (wenn ich es richtig in Erinnerung habe sogar zweimal 10GB Lan) und verbraucht dennoch weniger als ein Penryn, bei vermutlich Leistung in ähnlichen Regionen, obwohl P.A. Semi nicht solche hochwertigen Fertigungsmöglichkeiten wie Intel hat.
Dazu würde ich gerne Benchmarks sehen. Das bezweifel ich jetzt einfach mal.
Ich schreibe in "Regionen" vom Penryn/Merom. E ist sicherlich langsamer.
Brauchbare Daten habe ich auch nicht, ausser vielleicht innoffizielle Aussagen, wenn ich sie nochmal suche, die aber nicht vertrauenswürdig sind.
Übrigens ist seit dem P6 der Anteil an Legacy-Transistoren sicher gesunken. Die ganzen Optimierungen sind eher im Backend.
Wobei man da eh nicht so sauber trennen kann. Auch ein G5 hat einen Dekoder der in Microinstructions umwandelt. Ist PPC dann auch "legacy"?
Auch fraglich inwiefern die Ausrichtung auf eine besonders stromsparende Architektur nicht auch bei x86 möglich gewesen wäre.
heise schreibt:
"Der effizienteste Hochleistungsprozessor der Welt ist jedoch nach den Darlegungen von P. A. Semi ihr PowerPC PA6T-1682M, begnüge er sich doch bei 2 GHz Taktfrequenz mit maximal 25 Watt Leistungsaufnahme. Und im typischen Betrieb soll der Energiebedarf nur zwischen 5 und 13 Watt liegen. Zum Vergleich: Laut Intel brauchen die Low-Voltage-(LV-)Versionen des Mobilprozessors Core 2 Duo mit 4 MByte L2-Cache lediglich 17 Watt Thermal Design Power (TDP), erreichen aber höchstens 1,5 GHz (Core 2 Duo L7400). Der PA6T mit zwei 64-bittigen PowerPC-Kernen und einem gemeinsamen L2-Cache von 2 MByte belegt bei Fertigung in 65-Nanometer-Technik 115 Quadratmillimeter Siliziumfläche. Mit rund 23 000 „Clock Gates“ machen die PA-Entwickler intensiv vom Clock-Gating Gebrauch, weit mehr als IBM bei Power6. Jeder Kern, die Cache-Arrays sowie die Controller für Speicher und I/O haben jeweils separate Spannungsversorgungen. Mit dieser feinkörnigen - und auch aufwendigen - Takt- und Spannungssteuerung quetscht P. A. Semi pro Watt die doppelte MIPS-Leistung eines Power6 aus ihrem Chip.
Laut P. A. Semi interessieren sich bereits 100 Firmen für den PWRficient PA6T-1682M. Er ist vor allem für Embedded-Systeme gedacht: Das integrierte I/O-Subsystem steuert acht PCI-Express-Ports an und enthält zwei 10-Gigabit-Ethernet- und vier Gigabit-Ethernet-Controller."
http://www.heise.de/ct/07/06/056/default.shtml
Seit wann ist Ghz eine vernünftige Vergleichsbasis? Ohne Benchmarks ist das doch wertlos. Und das Clock-Gating ist eben etwas was enorm Energie spart. Das hat aber nicht die Bohne mit PowerPC zu tun.
Es gibt Stimmen im Netz, die sagen, dass Apple gewisse Benchmarks verschwinden gelassen hat, da sonst deren "Switch-Begründung" adsurdum geführt werden würde... kann sein, dass es nur Bullshit ist, kann aber sein, dass auch ein wahrer Kern dran ist.
Jedenfalls bin ich überzeugt, dass Apple nicht aus technischen Gründen weggegangen ist, sondern gemerkt hat, dass die Welt sich um x86 dreht und man dort nur Ressourcen "verschwendet", die bei anderen Entwicklungen wie iPhone besser aufgehoben sind.
Wer hat's denn grad überhaupt von Apple? Wenn man auch nur das Wort PPC erwähnt kommen sie aus allen Ecken angesprungen.
Und ja, ich glaube sehr wohl dass Penryn (und Nehalem erst recht) derzeit die schnellsten Out-Of-Order-CPUs sind die es gibt in dem Segment das sie abdecken. POWER, Itanium usw. jetzt mal beiseite gelassen, das ist kein Massenmarkt.
Apple hat eben P.A. Semi aufgekauft und liefert diesen Prozessor AFAIK nur noch ans Militär - weil sie wohl müssen.
http://penguinppc.org/news/2008/07/14/apple_pasemi_support
Warum denn nicht an andere, wo die ganzen Interessente dran waren? ;)
Haarmann
2008-07-25, 09:02:25
Und noch immer erklärt dem armen Threadersteller keiner von euch, weswegen man 32 Beinchen hat, aber nicht alle davon nutzt.
Die RAMs machen da schlicht nicht mit... bei 128 Bit Breite werden die "Häppchen" nochmals grösser.
Abgesehen davon...der Glaube mag Berge versetzen... aber interessiert keine Sau.
BlackBirdSR
2008-07-25, 09:28:38
BlackBirdSR
Die klassische FPU mit ihrem "wundervollen" Stack ist auch verstorben... der 8087 ist also in Pension geschickt worden - fehlt nur noch der 8086. Die Mehrzahl der alten DOS Krücken läuft ohnehin nicht mehr direkt...
Wo ist sie verstorben? Starte ich heute in einer 64-Bit Umgebung einen 32-Bit Prozess, so nutzt dieser ohne Skrupel die x87-Funktionen. Von verstorben kann keine Rede sein. Eher von veraltet und abgelöst.
Trotzdem wird die x87 beibehalten und ist vollständig nutzbar. Wer regt sich darüber auf? In ein paar Jahren braucht man den Befehlssatz dazu vielleicht gar nicht mehr. Dann stellt sich die Frage: Wie hoch ist der Aufwand das alles zu entfernen, und bringt es mir überhaupt etwas?
Gleiches trifft doch auf alles andere zu, auch den Real Mode. Und wie ich oben schon angesprochen hatte: Was passiert wenn ich den Real-Mode jetzt sofort in Nehalem entferne? Sind die entstehenden Probleme vielleicht um Größenordnungen gravierender als das Mitschleppen von minimalem Ballast?
Schon klar, dass hier viel minimaler Ballast zusammenkommt. Trotzdem sind x86 die schnellsten, billigsten effizientesten CPUs die man für den breiten Einsatz in so vielen Feldern bekommen kann. Keine andere "saubere" µArch hat das geschafft.
Ich verteidige auch gar nicht den Ballast. Ich versuche nur meinen Standpunkt darzustellen, dass es sich nicht unbedingt lohnt ihn loszuwerden. Wenn es wirtschaftlicher ist ihn vorerst zu behalten (weil alles darauf ausgelegt ist), dann bleibt er auch drinn. Das ist eine ganz simple Rechnung.
Trotzdem sind x86 die schnellsten, billigsten effizientesten CPUs die man für den breiten Einsatz in so vielen Feldern bekommen kann.
Aber (noch?) nicht dort, wo Intel mal hin will und mit Atom angefangen hat.
Mit solchen Aussagen muss man IMHO aber vorsichtig sein, denn das liegt zum Großteil wohl daran, dass alle Welt nach x86 schreit und deswegen bei alternativen Architekturen weniger Investiert wird, da das ja logisch ist.
Irgendwo hat mal jemand hier im Forum das damalige Budget von dem oben angesprochenem P.A. Semi gepostet im Vergleich zu Intel (Chipentwicklung). Das waren Welten^10. Vielleicht ist x86-Entwicklung ja sogar teuer, wenn man solche Zahlen von Startup (von 0 auf 100) gegenüber stellt, fragt man sich was Intel mit dem Geld macht? OK, kann man vielleicht nicht genau zuordnen, was wirklich Intel Geld gemacht hat.
BlackBirdSR
2008-07-25, 09:51:34
Aber (noch?) nicht dort, wo Intel mal hin will und mit Atom angefangen hat.
Mit solchen Aussagen muss man IMHO aber vorsichtig sein, denn das liegt zum Großteil wohl daran, dass alle Welt nach x86 schreit und deswegen bei alternativen Architekturen weniger Investiert wird, da das ja logisch ist.
Natürlich... x64 ist nicht einfach ein Produkt. Es ist eine Welle die ein Eigenleben besitzt. Das spüren nicht nur Intel und AMD, sondern der ganze Markt. Deswegen bleiben AMD und Intel gar keine große Wahl, als eben x64 Prozessoren für jeden Markt zu entwickeln den sie erschließen können. Im Fall von Intel eben Atom, bei AMD Bobcat.
Aber warum entwickelt man keine eigene, saubere und effiziente ISA? Weil man dann einer unter Vielen wäre. Allerdings ohne Support und Userbasis. Intel mag eine gigantische Marktmacht besitzen. Ich behaupte aber, dass ein Großteil davon nur auf dem Rückenwind durch x64 basiert. Ohne diesen Bonus ist man auch nur ein reicher und starker Mitbewerber, kein übermächtiges Monster.
Es ist die perfekte Symbiose, oder gegenseitiger Parasitismus: Intel/AMD kann nicht ohne x64, x64 nicht ohne Intel/AMD
Haarmann
2008-07-25, 10:01:42
BlackBirdSR
Ich empfinde natürlich nur noch 64 Bit SW als modern - aber da kann man geteilter Meinung sein. Bei 64 Bit ist sie (endlich) verstorben... und denke nicht, dass viele ihr nachtrauern. Ich hege nach wie vor die Hoffnung, dass man früher oder Später auch den Realmode mit auf den Kompost wirft - aber gleich mitsammt all den architektonischen Merkwürdigkeiten...
Intel wirft ja gerne "alte" Dinge weg... ATA Ports, PS2 Ports, Serial, ... da wär der Realmode auch mal fällig. Ich hab jedoch für Intel auch Verständnis, denn deren Pläne hat AMD mit der 64 Bit Erweiterung bestimmt durchkreuzt.
Gehe ich mal davon aus, dass THG keinen Mist gebaut hätte ;).
291 mio für C2D mit 4MB
167 mio für C2D mit 2MB
1 mio nehm ich noch für die Logik des L2
Ergäbe 42 mio "netto"
Davon wären dann, ich extrapoliere mal die 40% des PPro soso lala, 6 mio (2*3) für die Altlasten zuständig... wär zwar nur 1/7, aber den kann man gemütlich sparen. Ich meine... nur fürs "Booten" sind das doch ne Menge Transistoren - oder?
Seit den 64 Bit OS ist die alte 16 Bit SW ja nicht mehr lauffähig, wobei die zumeisst wegen schusseliger Programmierung ohnehin nicht mehr lief.
Wenn man ohnehin auf EFI "upgraden" will, dann kann der Realmode gleich mit entsorgt werden imho - ganz besonders nebenher auch der 286 kompatible protected mode.
Ich geb Dir völlig recht, dass es unwirschaftlich ist im Moment diese Schritte zu tun, aber ich glaube nicht, dass dies beim Umstieg auf ein neues "BIOS" noch unwirtschaftlich ist.
BlackBirdSR
2008-07-25, 10:09:36
BlackBirdSR
Gehe ich mal davon aus, dass THG keinen Mist gebaut hätte ;).
291 mio für C2D mit 4MB
167 mio für C2D mit 2MB
1 mio nehm ich noch für die Logik des L2
Ergäbe 42 mio "netto"
Davon wären dann, ich extrapoliere mal die 40% des PPro soso lala, 6 mio (2*3) für die Altlasten zuständig... wär zwar nur 1/7, aber den kann man gemütlich sparen. Ich meine... nur fürs "Booten" sind das doch ne Menge Transistoren - oder?
Du hast das völlig falsch verstanden.
1. Punkt: du kannst die 40% nicht extrapolieren, da wir keine Ahnung haben wie viel Transistoren ins FrontEnd, wieviele ins Backend gewandert sind. Der Koeffizient kann sich extrem verschoben haben.
2. Punkt: noch viel gravierender: Du redest von Altlasten nur fürs Booten. Wenn du dich bei Stokes etwas einliest wirst du feststellen, dass x86-Legacy sich hier auf den gesamten Prozess der Zerlegung der x86-CISC in x86-µop Befehle handelt.
Ansonsten werden wir uns ja langsam einig: Ballast der ruhig verschwinden kann, was allerdings nicht immer gleich wirtschaftlich ist.
mekakic
2008-07-25, 10:11:11
Aber warum entwickelt man keine eigene, saubere und effiziente ISA? Weil man dann einer unter Vielen wäre. Allerdings ohne Support und Userbasis. Intel mag eine gigantische Marktmacht besitzen. Ich behaupte aber, dass ein Großteil davon nur auf dem Rückenwind durch x64 basiert. Ohne diesen Bonus ist man auch nur ein reicher und starker Mitbewerber, kein übermächtiges Monster. Jo, wie bei IA64. Von dem man in Zukunft wohl auch eher weniger als mehr sehen wird.
Haarmann
2008-07-25, 10:32:52
BlackBirdSR
Ich hab sie nur einfach extrapoliert, weil das sehr einfach geht. Es ging mehr darum, dass bei all den schönen Transistoren die Mehrzahl des Zuwachses seit dem PPro nicht in Logik gewandert ist und somit die Altlasten durchaus noch was ausmachen. Ich weiss auch nicht, wieviel die SIMD, FPU und Co Units "fressen". Die kennt ein PPro ja auch nicht.
Imho sollte man beim Moorschen Gesetz den Cache nie dazuzählen.
Es wäre auch mal interessant zum Beobachten, wieviel Ballast man abwerfen könnte, wenn man nur noch das neue x64 Befehlsset beibehielte. Da müsste ich jedoch wild spekulieren.
Ergo abwarten, bis es wirtschaftlich wird, den Ballast still sterben zu lassen. Imho ist die x87 sehr still von uns gegangen. So still wie sie eigentlich gekommen ist.
BlackBirdSR
2008-07-25, 10:37:39
BlackBirdSR
Ergo abwarten, bis es wirtschaftlich wird, den Ballast still sterben zu lassen. Imho ist die x87 sehr still von uns gegangen. So still wie sie eigentlich gekommen ist.
Und während du das schreibst, wurde deine x87 dazu benutzt ;)
Haarmann
2008-07-25, 11:32:38
BlackBirdSR
Leider hab ich noch nicht jegliche Software in 64 Bit ... der Opera Browser ist 32 bittig... den IE mag ich nicht, auch wenn der auch in 64 Bit vorhanden wär.
Da vermisse ich unter Windows schwer die Lösung, wie in Gentoo alles selbst kompilieren zu dürfen... (wobei ich immer auf size kompilierte)
Aber die grundlegende Frage bleibt irgendwie im Raume - wieso werden soviele Adressbeinchen herausgeführt, wenn diese faktisch zT nutzlos vor sich hin dümpeln. Man kann schwerlich einem RAMModul mit 8 8 Bit breiten Chips erklären, es soll nun aus Chip 1-4 Stelle A liefern und Folgende und aus Chip 5-8 Stelle A+1 und Folgende.
Aber die grundlegende Frage bleibt irgendwie im Raume - wieso werden soviele Adressbeinchen herausgeführt, wenn diese faktisch zT nutzlos vor sich hin dümpeln. Man kann schwerlich einem RAMModul mit 8 8 Bit breiten Chips erklären, es soll nun aus Chip 1-4 Stelle A liefern und Folgende und aus Chip 5-8 Stelle A+1 und Folgende.
Die Adressierung zwischen Speichercontroller und RAM-Modulen ist etwas anderes als die Kommunikation zwischen CPU und Peripherie auf dem Adressbus. Es gibt da nirgends ungenutzte Leitungen.
Mit 32-Bit-Zeigern kann man 2³² Dinge logisch adressieren. Bei fast allen CPU-Architekturen sind diese "Dinge" Bytes, weil enorm viel existierende Software darauf ausgelegt ist, Bytes adressieren zu können.
Bei ASICs (anwendingsspezifischen Chips, z.B. GPUs) kann die kleinste logisch adressierbare Einheit auch mal breiter sein wenn Byte-Granularität nicht gebraucht wird und man nicht auf existierende Software Rücksicht nehmen muss.
Haarmann
2008-07-25, 18:13:32
Xmas
Die Frage ist doch... wozu nutzt man etwas, was keinen Sinn ergibt?
Man kann nur zB 16 Bit Häppchen, also ohne letztes Bit, einlesen - wozu sollte man sich die Mühe nehmen, zuzulassen, dass es auch "ungerade" geht?
Solange die Register teilbar sind, in Bytehäppchen, ists doch Banane, ob ich nun in AH oder in AL das Byte hab. Bei 32 Bit Registern gibts dann halt 4 Teile... bei 64 Bit 8. Davon geht die Welt auch nicht unter.
Also was war zuerst - das Ei oder das Huhn. Eine meiner Lieblingsfragen, die ich immer wieder mit Ei beantworte.
Die Frage ist doch... wozu nutzt man etwas, was keinen Sinn ergibt?
Man kann nur zB 16 Bit Häppchen, also ohne letztes Bit, einlesen - wozu sollte man sich die Mühe nehmen, zuzulassen, dass es auch "ungerade" geht?
Solange die Register teilbar sind, in Bytehäppchen, ists doch Banane, ob ich nun in AH oder in AL das Byte hab. Bei 32 Bit Registern gibts dann halt 4 Teile... bei 64 Bit 8. Davon geht die Welt auch nicht unter.
Wie kommst du darauf dass dies keinen Sinn ergäbe? Bei Zeichenkettenverarbeitung beispielsweise muss man ständig einzelne Bytes ansprechen, also adressieren können. Statt dass man nun die letzten beiden Bits des Zeigers wegmaskiert und einen 32-bit-Wert in ein Register liest, dann in einem zweiten Schritt nun die letzten beiden Bits nimmt um das Byte im Register zu indizieren, hat die CPU für diesen häufig vorkommenden Fall eben Hardware die dies in einem Schritt macht. Das ist sinnvoll, und sicher nicht nur bei x86 so.
Zudem würde es so ziemlich jeden bestehenden Programmcode inkompatibel machen. Absoluter Käse eben.
Haarmann
2008-07-26, 01:12:48
Xmas
Und wo ist das Problem, dass ich bei einer Zeichenkette statt alle Bytes einzeln in AL zu analysieren, mir einfach den Block (4 Bytes) in "EAX" reinlude und dann die Bytes mit EAX0-3 anspräche?
Ich kann nix dafür, dass Intel das Gefühl hatte, EAX nicht in Bytes unterteilen zu müssen.
Sicherlich wird irgendwer ne Anwendung dafür finden, AL mit x0000 und AH mit x5487 zu füllen. Aber wenn das nicht ginge... ginge die Welt unter?
Coda
Jede Erweiterung macht bestehenden Code so nützlich wie nen Kropf... und?
Bei Hochsprachen passts der Compiler an, was den Progger nicht kümmert und bei ASM ists soweiso klar, dass der alte Code am Ende ist.
P.S. Wer unausgerichteten Code proggt, den sollte man fristlos entlassen und nie nie wieder nen Proggi schreiben lassen!
Grestorn
2008-07-26, 08:51:09
@Haarmann: Erst willst Du unbedingt den Real-Modus wegdrücken und jetzt auch noch die Byte-Adressierung.
Bei beidem kann man sicher der Meinung sein, dass es auch ohne geht - andererseits bringt es schlicht gar nichts, bei einer bestehenden Architektur so etwas zu ändern, außer jeder Menge Ärger und Inkompatibilitäten bzw. Performanceverluste um um die Software dazu zu bewegen, dennoch zu funktionieren.
Also wozu?
Wenn ich eine ganz neue Plattform aufbaue, werde ich mir evtl. überlegen ob ich eine Byte-Adressierung brauche oder nicht. Aber nicht beim x86.
Haarmann
2008-07-26, 09:59:21
Grestorn
Es geht weit eher ums Ausrichten von Daten im Speicher. Und ich beginne einfach mit dem 8086 - das lässt sich aber auch auf spätere Errungenschaften übertragen.
Ist es sinnvoll zuzulassen, dass 16 Bit Werte ab ungerader Adresse gelesen werden können, wenn dies gar nicht direkt geht und man sowieso zwei Zugriffe dazu benötigt? Ich sage Nein, denn ohne dies "Feature" kann man leben und kriegt dafür auch Vorteile.
Wenn man dies gar nie zugelassen hätte, kriegte man den doppelten Adressraum und mehr Geschwindigkeit frei Haus.
Bei 32 Bit würden das dann analog dazu 32 Bit Häppchen sein und somit gäbs 16GB, statt 4 GB.
Ich habe nie gesagt, dass man das Heute noch einführen sollte - wie das wohl wieder irgendwer reininterpretiert. Meine Ansicht ist, dass man das hätte tun sollen, beim Wechsel vom 8086 auf den 386 (und beim 8086 schon auf die 16 Bit ausgerichtet).
Das grösste Hindernis auf diesem Weg wären imho die Ports gewesen... aber auch das liesse sich lösen.
Es geht da wirklich um den Plattformwechsel und nicht ums Hier und Heute, wo 32 Bit sich sowieso bald erledigt haben wird - hoffentlich.
Grestorn
2008-07-26, 10:44:34
Ist es sinnvoll zuzulassen, dass 16 Bit Werte ab ungerader Adresse gelesen werden können...
Ja, ist es, weil x86 SW das seit 28 Jahren macht und man ihr das nicht von Heute auf Morgen abgewöhnen kann. So einfach ist das.
Haarmann
2008-07-26, 10:54:49
Grestorn
Und war es sinnvoll, dies vor 28 Jahren einzuführen?
Grestorn
2008-07-26, 10:56:52
Spielt das eine Rolle?
Haarmann
2008-07-26, 11:02:13
Grestorn
Das ist die eigentliche Frage, die ich gestellt habe... ergo natürlich!
Und war es sinnvoll, dies vor 28 Jahren einzuführen?
Es ermöglicht einfach zu benutzende Arrays aus 1 Byte + 1 Word ohne Speicherverschwendung.
Welchen Wettbewerbsvorteil hätte man denn damals dadurch gehabt diese Funktion wegzulassen? ;)
Haarmann
2008-07-26, 12:16:20
Trap
Durch Intels herrliche Segment Offset Idee hat sich das Thema Einfach gleich von Anfang an erledigt... spätestens wenn Dein Array 64 KB überschreitet war das Thema Einfach vom Tisch.
Ob der grössere Aufwand die weit grössere Geschwindigkeit aufwiegt, muss jeder selber wissen. Bytes müssen in beiden Fällen nicht verschwendet werden.
Weitsicht war beim 8086 bestimmt kein Kriterium - das geb ich zu ;).
Ob höhere Geschwindigkeit ein Wettbewerbsvorteil für den 8086 gewesen wäre ... schwer zu sagen, denn schnell war das Teil eigentlich ohnehin nicht.
Ob der grössere Aufwand die weit grössere Geschwindigkeit aufwiegt
Woher soll die größere Geschwindigkeit denn kommen? Garantiert nicht durch das Weglassen von Hardware.
Unaligned Speicherzugriffe sind nicht toll, aber mit Hardwareunterstützung sind sie schneller als ohne.
Haarmann
2008-07-26, 15:10:16
Trap
Wenn ich nur ausgerichtete Werte der vollen Breite habe, dann bin ich schneller...
Es wird Heute nicht wenig Hardware verbraten gerade solche unsinnigen Zugriffe zusammenfassen zu können. Ohne die Möglichkeit dieser Zugriffe, ersparst Dir Hardware, die Du andersweitig nutzen könntest.
Ist wie BCD Funktionen in den Nibbles - sehr einfach zum Nutzen, aber eigentlich ein völliger Murks und Schwachsinn.
Wenn ich nur ausgerichtete Werte der vollen Breite habe, dann bin ich schneller...
Das ist dann aber auf der tatsächlich vorhandenen Hardware genauso schnell wie auf der von dir vorgeschlagenen.
Es wird Heute nicht wenig Hardware verbraten gerade solche unsinnigen Zugriffe zusammenfassen zu können. Ohne die Möglichkeit dieser Zugriffe, ersparst Dir Hardware, die Du andersweitig nutzen könntest.
Welche Art von anderweitigem Nutzen meinst du? Es fällt den Chipdesignern offensichtlich nichts besseres ein, sonst würden sie nicht 30% mehr Transistoren in Cache verbraten um damit 5% Performance zu erreichen...
Oder bei Quadcores gleich 100% mehr Transistoren für <5% mehr Leistung in vielen Anwendungen ;)
Und wo ist das Problem, dass ich bei einer Zeichenkette statt alle Bytes einzeln in AL zu analysieren, mir einfach den Block (4 Bytes) in "EAX" reinlude und dann die Bytes mit EAX0-3 anspräche?
Ich kann nix dafür, dass Intel das Gefühl hatte, EAX nicht in Bytes unterteilen zu müssen.
das kann man mit SIMD Erweiterung bequem durchführen
Haarmann
2008-07-26, 17:59:32
Trap
Ich habe nie behauptet, das sei nicht so... ich stellte nur in den Raum, dass man es auch zur Konvention hätte machen können und damit sowohl Adressbeine, Zeit und Transitoren eingespart hätte. Im Gegenzug wäre etwas Komfort auf der Strecke geblieben...
Zu Zeiten des 8086 war da sicher noch Einiges drin... ein paar Register mehr zB ;).
Man könnte jetzt noch spekulieren, wieviele push und pop durch doppelte Registerzahl vermieden werden könnten.
Ich kann Dir nebenher bei Deiner "Transistor für was?" Analyse nur zustimmen...
pest
Absolut richtig - die ersten SIMD Befehle waren aber imho die BCD Befehle.
Nur wieso sollte nur die FPU für SIMD herhalten?
Nur wieso sollte nur die FPU für SIMD herhalten?
macht sie doch nur bei MMX (Ext.) und 3DNow
Haarmann
2008-07-27, 09:24:25
pest
Drum ersetzt bei x64 SSE2 auch gleich die x87?
Und wo ist das Problem, dass ich bei einer Zeichenkette statt alle Bytes einzeln in AL zu analysieren, mir einfach den Block (4 Bytes) in "EAX" reinlude und dann die Bytes mit EAX0-3 anspräche?
Es benötigt zusätzliche Logik, genau wie die Alternative. Und ich glaube du überschätzt den Aufwand für unausgerichtete Speicherzugriffe.
Desweiteren vermischst du hier zwei Dinge: Ausrichtung und Adressierungsgranularität. Bei ARM beispielsweise müssen Daten nach ihrer Breite ausgerichtet sein, dennoch ist die Adressierungsgranularität 1 Byte. Denn sehr viel Software muss einzelne Bytes ansprechen können, und mit einem 32-Bit-Wert kann man nun mal nur 2³² Objekte unterscheiden.
Oder würdest du ernsthaft ein Speichermodell wollen bei dem man zwar 16 GiB adressieren kann, einzelne Bytes jedoch nur bis 4 GiB, so dass man Zeichenketten nur im unteren Viertel des Speichers ablegen kann?
Und nochmal, vergiss bitte den Unsinn mit den "Adressbeinen".
Drum ersetzt bei x64 SSE2 auch gleich die x87?
Das machte man damit man den FPU-Stack los hat. Übrigens ist das eine reine OS-Entscheidung. Man kann unter Linux weiterhin x87 unter x86-64 verwenden.
Haarmann
2008-07-27, 15:34:12
Xmas
Man muss sich dazu in eine Zeit zurückversetzen, bei der es keine Caches gab und keine "Bursts". Ausgerichtete 16 Bit = 1 Zugriff und Nichtausgerichtete 16 Bit = 2 Zugriffe - so einfach.
Die CPU hängt nunmal an ihrem Unterbau...
Wie gesagt ist es komplizierter mit 32 Bit Granularität zu arbeiten, wenns nur um Bytes geht - dafür stehen jedoch Register zur Verfügung. Das fällt einem natürlich bei Architekturen, wie Intel, die schlicht zuwenige Register haben, ziemlich schwer...
Adressbeine sind eben dort zu suchen, wo faktisch was gelesen wird... bei Intel wird wohl auch irgendwann mal die CPU dies Teil sein...
Coda
Da eine AMD64 CPU für nen Codesegment die 32 Bit Unterstützung aktivieren kann... steht auch x87 nix im Wege... nur gehts auch, wenn die diese Unterstützung deaktiviert bleibt?
Du kannst sogar MMX und x87 Code gleichzeitig verwenden ... schnell ist das nicht.
Man muss sich dazu in eine Zeit zurückversetzen, bei der es keine Caches gab und keine "Bursts". Ausgerichtete 16 Bit = 1 Zugriff und Nichtausgerichtete 16 Bit = 2 Zugriffe - so einfach.
Damals war ein Speicherzugriff relativ gesehen auch viel günstiger. Außerdem hindert einen ja niemand an ausgerichteten Speicherzugriffen.
Wie gesagt ist es komplizierter mit 32 Bit Granularität zu arbeiten, wenns nur um Bytes geht - dafür stehen jedoch Register zur Verfügung. Das fällt einem natürlich bei Architekturen, wie Intel, die schlicht zuwenige Register haben, ziemlich schwer...
ARM hat mehr GPRs und benutzt trotzdem Adressen mit Byte-Granularität. Mehr Register ändern auch nichts daran dass ein 32-Bit-Pointer nur 2³² einzelne Bytes adressieren kann.
Seit ARMv6 werden übrigens unausgerichtete Speicherzugriffe unterstützt. Anscheinend sieht also nicht nur Intel Vorteile darin.
Haarmann
2008-07-27, 22:19:35
Xmas
Ich glaube nicht, dass es Intels zu jeder Zeit überlegene Produkte waren, welche diese Firma zum Marktführer machten...
Auch der Urahne des ARM (Archimedes mein ich damit) ging bekanntlich unter wie ein Stein - was nicht an schlechter Leistung lag.
Man sagt, der ARM sei als Nachfolger für den 6502 gedacht gewesen - möge dem so sein - ich weiss es nicht. Zu der Zeit gabs nichtmals Festplatten mit annährend 4 GB, die irgendwer bezahlen könnte. Wenn man bedenkt, dass Intel beim 8086 noch an den 8080 (drum klappte es auch mit dem CPM Emu) dachte (das ist leider zu deutlich bemerkbar und wird nach wie vor mitgeschleppt), dann ist das ein gigantischer Fortschritt. Aus meiner Sicht der Dinge hat mans jedoch verpasst, gleich die Vorteile von Einheitslängen und Co komplett umzusetzen.
Bei einheitlich langen Befehlen, die Kürzer denn ein Argument sind, hätte man es sich sogar überlegen können, die von Neumann Architektur mit über Bord zu werfen. Ein NX Bit hätte sich damit auch erledigt...
In der Theorie wird auch niemand gehindert fehlerfreie Software zu schreiben - die Praxis sieht trotzdem anders aus.
Letzten Endes siehts doch eher so aus, dass was gemacht werden kann, auch gemacht wird. Frei nach James Dean - Denn sie wissen nicht, was sie tun.
Da eine AMD64 CPU für nen Codesegment die 32 Bit Unterstützung aktivieren kann... steht auch x87 nix im Wege... nur gehts auch, wenn die diese Unterstützung deaktiviert bleibt?
Du redest mal wieder wirr. Ein 64-Bit-Prozess kann garantiert keinen x87 Code enthalten.
Ein 32-Bit-Prozess kann das natürlich aus Gründen den Abwärtskompatibilität.
Haarmann
2008-07-28, 11:29:05
Coda
Du widersprichst Dir damit ja selber...
Das machte man damit man den FPU-Stack los hat. Übrigens ist das eine reine OS-Entscheidung. Man kann unter Linux weiterhin x87 unter x86-64 verwenden.
nur mir eben nicht.
BlackBirdSR
2008-07-28, 12:11:29
Coda
Du widersprichst Dir damit ja selber...
nur mir eben nicht.
hättest du aufgepasst, und die eigene Diskussion verfolgt, wüsstest du um was es genau geht. Du selbst hast x64 als AMD64-Version der Windowssysteme angeführt, und damit das Thema in genau diesen Bereich verschoben. (du erinnerst dich sicherlich x64=SSE2 statt x87) Es ist nur natürlich, dass Coda eben auch dort weiter macht.
Dass du jetzt plötzlich wieder auf globale Bereiche ausdehnst, ist nicht die feine Art. Wie soll man da noch angenehm diskutieren?
Ich für meinen Teil lass das lieber.
Zu der Zeit gabs nichtmals Festplatten mit annährend 4 GB, die irgendwer bezahlen könnte.
Ein weiterer Grund warum es Unsinn gewesen wäre Zeiger mit größerer Granularität als Bytes zu verwenden.
Haarmann
2008-07-28, 13:05:19
Xmas
Kommt drauf an, was Deine Basis ist. Bei Intel wars mindestens die 4te Generation und bei Acorn die Erste und eigentlich aufs Gerät genagelt... da erwartet man durchaus gewisse Lerneffekte auf der einen Seite und Fehler auf der Anderen. Gerade mit dem Speichermanagement hat sich Intel ja nicht gerade mit Ruhm bekleckert...
Verglichen mit Motorola war Intel schlicht Jahre hinterher und hat eigentlich nie mehr erreicht, denn Motorola 1979 ... ich bin mir nicht sicher, aber ich glaube der mag ungerade Adressen nicht wirklich.
BlackBirdSR
Das OS stellt einzig die gewohnte 32 Bit Umgebung zur Verfügung oder eben nicht. Die CPU Umschalten kannst auch so... da Coda das auch schon für den Protected Mode so sah... und einfach umschalten würde, egal ob eine Umgebung da ist... da ists nur logisch, dass auch ich dort weitermache.
Ich kann nichts dafür, wenn gewisse Leute laufend Mist in meine Aussagen hineininterpretieren...
Wenn ich mir nicht sicher bin, wie ich was zu verstehen hätte und dies als zentral ansähe, dann frage ich einfach nach. Erspart viel böses Blut.
Verglichen mit Motorola war Intel schlicht Jahre hinterher und hat eigentlich nie mehr erreicht, denn Motorola 1979 ... ich bin mir nicht sicher, aber ich glaube der mag ungerade Adressen nicht wirklich.
Ich glaube du bist etwas arg romantisch verklärt was das angeht.
Ich kann nichts dafür, wenn gewisse Leute laufend Mist in meine Aussagen hineininterpretieren...
Doch kannst du, weil es wirklich sehr schwer verständlich ist was du schreibst.
Kommt drauf an, was Deine Basis ist. Bei Intel wars mindestens die 4te Generation und bei Acorn die Erste und eigentlich aufs Gerät genagelt... da erwartet man durchaus gewisse Lerneffekte auf der einen Seite und Fehler auf der Anderen. Gerade mit dem Speichermanagement hat sich Intel ja nicht gerade mit Ruhm bekleckert...
Verglichen mit Motorola war Intel schlicht Jahre hinterher und hat eigentlich nie mehr erreicht, denn Motorola 1979 ... ich bin mir nicht sicher, aber ich glaube der mag ungerade Adressen nicht wirklich.
Und obwohl der 68k ausgerichtete Speicherzugriffe benötigt, verwendet er dennoch immer Byteadressen.
Haarmann
2008-07-28, 14:24:26
Coda
Motorola hat eben eingesehen, dass der 6800 eine Sackgasse ist und ist beim 68000 neue Wege gegangen, die für einige Jahre tauglich waren. Die schauten also nach Vorne und Intel schaute immer nur in eine Richtung - nach Hinten (Zeitachse). Dabei kommt eben nichts Revolutionäres raus...
Vergleiche selbst mal die Ideen des 68k mit denen des 80286... der Vergleich ist keineswegs unfair für Intel.
Wenn Du etwas nicht verstehst, so kannst Du jederzeit nachfragen. Als Berner ist Hochdeutsch eine Fremdsprache, weswegen der Berner bei der Einschulung als Erstes mit hochdeutscher Grammatik gefoltert wird - das wirkt sich aus. Ich versuche jeweils schon die Sätze kurz zu halten...
Xmas
Das liegt beim 68k aber auch daran, dass es kein richtiger 32 Bit Prozessor ist. Ein Ausrichten auf Langwörter (68k Definition), wie ich vorschlug, hätte immer einen Doppelzugriff erfordert - beschleunigt das Ganze also nicht (Was später beim 386SX sehr gut bewiesen wurde). Ein Ausrichten auf Wörter wiederum wäre zukunftsuntauglich und unlogisch gewesen. Da machte das Verweilen bei Bytes auch Sinn - nicht nur des Baujahres wegen.
Nebenher ist der 68k im Prizip nur ein verdoppelter 8 Bitter... revolutionär ist das dann eben auch nicht, aber klug und auch bewährt.
Das liegt beim 68k aber auch daran, dass es kein richtiger 32 Bit Prozessor ist.
Es liegt vor allem daran dass sehr viel Software einzelne Bytes ansprechen muss. Da ist es nun einmal wenig sinnvoll, etwas anderes als Byteadressen zu verwenden.
Haarmann
2008-07-28, 15:10:30
Xmas
Solange man nicht von Anfang an SIMD im Hinterkopf hat, wie zB bei BCD, ist der Ansatz mit den grösseren Häppchen, seien das 16, 32 oder 64 Bit, nur halb so interessant - da stimme ich Dir zu.
Ein Byte kommt ja selten alleine... blockweise Verarbeitung ohne Blockbefehle ist ja nur halb so lustig.
Nur für Kreationen wie rep movsb hab ich selbst bei nem 8086 kein Verständnis.
Intel führt mit SSE4.2 sogar neue Befehle ein die einen ganzen String verarbeiten.
Ectoplasma
2008-07-28, 17:24:43
Nur für Kreationen wie rep movsb hab ich selbst bei nem 8086 kein Verständnis.
Wieso nicht? Verschiebt der Befehl wirklich nur byte-weise oder was ist der Grund?
Selbst wenn das so wäre. Wo ist das Problem? MOVSB ist dazu da Strings zu verarbeiten und da gab's und gibt's immer noch genug 8-Bit-pro-Char-Daten.
Verglichen mit Motorola war Intel schlicht Jahre hinterher und hat eigentlich nie mehr erreicht, denn Motorola 1979 ... ich bin mir nicht sicher, aber ich glaube der mag ungerade Adressen nicht wirklich.
der 68000 mag ungerade Adressen in der Tat nicht (immer) - produzierte dann im ungünstigsten Fall eine Guru Meditation nach der anderen. Ab 68020 war es mit den ungeraden Adressen (nicht mehr ganz so) schlimm. (so 1000%-ig weiss ichs im Detail nimmer)
Haarmann
2008-07-28, 17:48:10
No.3
Midestens ein JSR "Ungerade" machst genau einmal ;).
Coda
Mal abgesehen davon, dass man das 1985 hätte einführen können...
Kann ich diese Befehle auf RAX, EAX oder AX anweden?
Gerade für diese Stringbefehle (rep movsb) wird einiges an Logik verbraten, damit sie optimiert werden...
Ectoplasma
Ein alter 8088 täte das ja ohnehin... der 8086 würgt sich dabei auch einen ab. Irgendwann hat man das dann imho abgefangen und automatisch richtig zusammengefasst...
Betrifft nebenher die ganzen alten Stringbefehle.
Kann ich diese Befehle auf RAX, EAX oder AX anweden?
He? Das Zeug arbeitet auf einer Speicheradresse.
Haarmann
2008-07-28, 18:15:22
Coda
Was doch meine Frage mit Nein beantwortet...
Vielleicht würde ich das aber gerne dort anwenden können?
Es ergibt gar keinen, aber sowas von überhaupt keinen Sinn was du gerade redest.
Offensichtlich weißt du absolut nicht was rep movsb überhaupt tut, geschweige denn wie es funktioniert.
Haarmann
2008-07-28, 19:58:38
Coda
Ich dachte es gehe um Deine SSE4.2 Befehle...
Dass Blockmoves nicht auf Register angewendet werden ist mir auch klar ;).
Die SSE4.2-Befehle arbeiten auch auf Strings im Speicher mit variabler Länge. Das ergibt auf Registern genausowenig Sinn.
Haarmann
2008-07-29, 06:59:45
Coda
Das war zu erwarten ... aber man fragt ja nach, um sicher zu sein.
Nur den Teil mit dem Sinn würd ich weglassen. Sinn macht es auch nicht, wenn ich die eine Art Operation in den Registern nur durchführen kann und die Andere nur im Speicher...
Abgesehen davon, muss nicht jeder gleiche Freude zeigen über PcmpEstrI, PcmpEstrM, PcmpIstrI und PcmpIstrM...
Ectoplasma
2008-07-29, 13:23:24
Abgesehen davon, muss nicht jeder gleiche Freude zeigen über PcmpEstrI, PcmpEstrM, PcmpIstrI und PcmpIstrM...
Eigentlich geht es dabei nur um die Performance, nicht darum, ob es einem Spass macht. Du hast die Wahlfreiheit diese Performance zu nutzen, oder eben nicht.
Haarmann
2008-07-29, 20:00:58
Ectoplasma
Würd mich durchaus mal interessieren, wann das, gesetzt den Fall ich hätte 64 Bit Register und nicht nur 32 Bit Register, wirklich was bringt... und ab welcher Länge etc.
Es ist nicht alle Gold was glänzt. MMX sah auch nützlicher aus, denn es je war ;).
BlackBirdSR
2008-07-29, 23:10:53
Es ist nicht alle Gold was glänzt. MMX sah auch nützlicher aus, denn es je war ;).
Nur wenn man sich nicht auf den Verstand und Fakten verlässt, sondern sich von dritten zuschwallen lässt.
Wenn irgendeinem ohne jegliche Ahnung etwas davon erzählt wird, wie Falcon4 3x schneller läuft, Soundkarten überflüssig werden und externe Modems komplett per Software ersetzt, dann entsteht eben dieser Hype.
Das war aber nicht nur bei MMX der Fall. Ich könnte dir aus dem Stand hunderte Beispiele schildern. Von der grandios gesteigerten Gleitkommaleistung des Phenom zur Revolution durch Virtual Reality Helme, bis hin zur Internetbeschleunigung durch ISSE.
Also lass uns diesen Pfad bitte nicht in diesem Thread beschreiten. MMX war dort nützlich, wo das Prinzip sich gut anwenden ließ. Der Nachfolger ist durchaus sehr mächtig, und damit hat sich die Sache. Mach bitte einen neuen Thread auf, wenn du darüber zu meckern wünscht.
Sinn macht es auch nicht, wenn ich die eine Art Operation in den Registern nur durchführen kann und die Andere nur im Speicher...
Natürlich tut es das. Es geht um Daten variabler Länge. Ein Register hat eine Länge von 1-8 Bytes. Wahnsinn. Da braucht man sowas.
Und nach dem Satz glaub ich wieder nicht dass du wirklich weißt was ein REP MOVSB tut.
Ectoplasma
2008-07-30, 00:20:11
Also lass uns diesen Pfad bitte nicht in diesem Thread beschreiten. MMX war dort nützlich, wo das Prinzip sich gut anwenden ließ. Der Nachfolger ist durchaus sehr mächtig, und damit hat sich die Sache. Mach bitte einen neuen Thread auf, wenn du darüber zu meckern wünscht.
:confused:
Wovon redest du? MMX wurde doch jetzt völlig unqualifiziert von Haarmann zu einem Thema in den Raum gestellt, über das wir uns gar nicht unterhalten hatten. Es geht um String Befehle und nicht um MMX. Und ich bezweifle langsam auch, dass Haarmann weiß, was die Befehle machen.
Haarmann
2008-07-30, 09:32:23
BlackBirdSR
Das war mehr als Zusatz gedacht fürs Sprichwort. Eben selbst nachdenken, ob man für etwas wirklich die Killeranwendung sichtet - oder auch nicht und sich dabei vor allem nicht von handselektierten Nischenanwendungen blenden lassen.
Coda
Schon wieder gehts nicht um rep movsb...
Wieso bist Du der Einzige, der das nicht merkt?
Ectoplasma
Ich hab einfach die Befehle gesucht und gefunden (So es die 4 genannten sind, wobei keiner widersprochen hat). Nun sei es mir doch erlaubt, den Nutzen des Befehls im Geiste zu analysieren und mögliche Anwendungen mir auszudenken. Das Ergebnis mag nicht für jede Person gleich sein, aber vom Hocker gerissen hat es mich nicht.
Ectoplasma
2008-07-30, 09:58:51
Ectoplasma
Würd mich durchaus mal interessieren, wann das, gesetzt den Fall ich hätte 64 Bit Register und nicht nur 32 Bit Register, wirklich was bringt... und ab welcher Länge etc.
Es ist nicht alle Gold was glänzt. MMX sah auch nützlicher aus, denn es je war ;).
Ich kann dir wirklich nicht genau sagen, ab welcher Länge es etwas bringt. Ich denke, um mal wieder aus REP MOVSB zurückzukommen, dass es sich ähnlich wie bei diesem Befehl verhält. Zumindest wird REP MOVSB von jedem C/C++ Compiler genutzt. Er ist mit Sicherheit eine ganze Ecke schneller, als eine Schleife, die sich aus herkömmlichen Assemberbefehlen zusammensetzt. Gleiches dürfte für die SSE4 Stringbefehle gelten. In SSE ist wirklich nicht alles Gold was glänzt, dennoch sollte man wissen, welche Befehle einen Schub bringen und welche nicht. Leider muss man hier von Hand optimieren, da die gängigen Compiler mit SSE kaum etwas anfangen können. Sie generieren zwar SSE Code, dieser ist aber alles andere als optimal. Hier sehe ich noch Verbesserungspotential.
Ich hab einfach die Befehle gesucht und gefunden (So es die 4 genannten sind, wobei keiner widersprochen hat). Nun sei es mir doch erlaubt, den Nutzen des Befehls im Geiste zu analysieren und mögliche Anwendungen mir auszudenken. Das Ergebnis mag nicht für jede Person gleich sein, aber vom Hocker gerissen hat es mich nicht.
Das klingt jetzt aber ganz anders und ist auch nachvollziebar.
Haarmann
2008-07-30, 10:59:40
Ectoplasma
Meine Gedanken waren eher beim Auffinden von bestimmten Zeichenfolgen im Speicher (sse 4.2 also)...
Aber nochmals zum rep movsb also... das wird imho in der CPU inzwischen optimiert - keineswegs schaufelt der noch Byteweise... ich sagte ja schon, ich weiss nicht mehr, ab wann man das tat. Kostet jedoch Logik/Transistoren.
rep movsb ist ein Blockmove Befehl (Blitter für Arme - wie ich Coda gegenüber schon erwähnt hätte). Gehen wir davon aus, dass wir im 32 Bit Mode arbeiten, gibts im ESI einen Pointer für die Quelle und in EDI einen Pointer fürs Ziel. In ECX steht die Grösse des Blocks.
Mal das ausgeschrieben...
LOOP:
MOV AL, [ESI]
MOV [EDI], AL
INC EDI
INC ESI
DEC ECX
JNZ LOOP
Dass es physisch Schwachsinnig ist Bytes zu schieben, statt die ganze Busbreite, liegt wohl auf der Hand...
Ich hoffe die SSE 4.2 sind aufgeklärt und das rep movsb Kapitel ist auch so dargelegt, dass es verstanden wird.
Ectoplasma
2008-07-30, 11:39:54
Mal das ausgeschrieben...
LOOP:
MOV AL, [ESI]
MOV [EDI], AL
INC EDI
INC ESI
DEC ECX
JNZ LOOP
Dass es physisch Schwachsinnig ist Bytes zu schieben, statt die ganze Busbreite, liegt wohl auf der Hand...
Natürlich ist das Schwachsinn. Ich frage mich nur, wer das so macht und ob es die CPU bei SSE 4.2 ebenfalls so macht. Das wäre in der Tat alles andere als optimal. Ich kann es mir nur wirklich nicht vorstellen, dass es so läuft.
Aber mal angenommen es wird die gesamte Busbreite genutzt, dann ist es doch völlig egal, ob es zusätzliche Transistoren kostet. Es werden im Verhältnis sowieso nur wenige sein. IMO.
Haarmann
2008-07-30, 12:04:02
Ectoplasma
Heute sind das Wenige - aber das sah auch schon anders aus.
Als der 8086 kam, da gabs keine GPR, sondern nur so Spezialregister...
Bei SSE geht das anders... das ist klar, aber man kann auf die XMM Register nicht die gleichen Befehle anwenden, wie auf die GPRs.
Oft ist es dann so, dass ein GPR Register mit SIMD-fähigkeiten gewünscht wäre - der Effekt ist dann entweder, dass man SIMD nicht nutzt oder man munter Daten herumschiebt. Beides imho suboptimal.
Wie schnell die SCASx und CMPSx Befehle sind, weiss ich zB nicht.
;;; Ein kleines Beispiel, wie man in den 32-Bit Protected Mode wechselt
;;; Bei Fragen kann man sich einfach an die ICQ-Nummer 338-417-614 wenden.
...
...
Coreboot v3
How coreboot starts after Reset
Whenever an x86 CPU wakes up after reset, it does it in Real Mode. This mode is limited to 1MiB address space and 64k offsets and the reset vector of the original 8086/88 was located at 0xFFFF0.
As there was no change even if we run current processors like P3, these newer CPUs also feels like they where start at 0xF0000:0xFFF0 after a reset. But they do not. The base of the code segment register is 0xFFFF0000 after reset, so the CPU generates a physical address of 0xFFFFFFF0 to the chipset. And the chipset is responsible to forward this area to the boot ROM. Its confusing: The CPU "thinks" it runs code at 0xF000:0xFFF0 but instead it uses code at 0xFFFFFFF0. The developers must have been tanked up when they realised this design into silicon.
On some chipsets there is an additional pitfall: The so called A20 gate. It was introduced to support full compatibility for the 80286 CPU with their predecessor 8086. When the old CPU accesses space "behind" the 0xFFFFF (=1MiB) limit, they wrap around to 0x00000. On 80286 and newer processors accesses above 0xFFFFF natively do not wrap around. The external A20 gate forces this wrap also on newer CPUs. On older CPUs its open after reset, so the CPU cannot generate addresses with A20 set.
http://www.coreboot.org/images/2/2a/Gatea20.png
Next pitfall on some chipsets is, if they are able to forward two address spaces to the boot ROM: 0xFFFF0000 and 0xF0000. If not and the opcode at the reset vector does something like "jmp 0xF000:xxxx" this crashes the machine immediately, as this will force the baseaddress of the code segment register to 0. After this, the CPU really outputs address with 0xFxxxx to the chipset. And if the chipset cannot handle the forwarding of two address spaces, the boot ROM cannot be accessed anymore. You are lost.
Next pitfall on some chipsets is, if they are able to forward two address spaces to the boot ROM: 0xFFFF0000 and 0xF0000. If not and the opcode at the reset vector does something like "jmp 0xF000:xxxx" this crashes the machine immediately, as this will force the baseaddress of the code segment register to 0. After this, the CPU really outputs address with 0xFxxxx to the chipset. And if the chipset cannot handle the forwarding of two address spaces, the boot ROM cannot be accessed anymore. You are lost.
How to escape from these restrictions?
First of all, we must ensure not to touch the baseaddress of the code segment register. This will keep us in the 0xFFFF0000 address space. We can ensure this by using branches only instead of jumps. So the opcode at the reset vector must be nothing else than a branch command! The next step depends on the used chipset. Does it open the gate A20 after reset? If yes, we must close it prior switching to Linear Flat Mode.
Weiter geht es hier: http://www.coreboot.org/Coreboot_v3
Bin darauf hierüber aufmerksam geworden: http://www.fscklog.com/2008/08/psystar-klagt-z.html#c128017044
Ganon
2008-08-27, 21:53:06
Bin darauf hierüber aufmerksam geworden: http://www.fscklog.com/2008/08/psystar-klagt-z.html#c128017044
Oh, "ut" wieder beim Fakten verdrehen ^^
Das Gerücht hält sich aber auch wirklich hartnäckig.
Das Gerücht hält sich aber auch wirklich hartnäckig.
Das hier ist aber dennoch interessant oder nicht?
http://www.coreboot.org/Coreboot_v3
Interessant ja, aber nichts neues. Ich kenne das Protected-Mode-Setup und seine Schwierigkeiten.
Das ist aber nichts womit ein normaler Entwickler in Berührung kommt, und wenn man einen Kernel schreibt sind solche Dinge das kleinste Problem. Vor allem schreibt man sie einmal und muss es danach nie wieder anfassen.
Wenn man erstmal im Protected-Mode ist hat man mit x86 ein modernes, gepagetes, flaches Speichermodell wie bei jeder anderen Architektur auch.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.