Diskussion:AMD64

Gibt es nicht auch Solaris 9 und 10 für das Ding oder bringe ich da was durcheinander?

--okorf 16:15, 3. Mär 2005 (CET)

---

Okay.

Die Architektur heißt x86-64.

Kurz vor Markteinführung des Opteron kam AMD dann mit der Bezeichnung AMD64, ebenso nennt intel es EM64T und genauso werden noch andere Hersteller ihre eigenen Marketingnamen dafür haben, falls es sich durchsetzen sollte.
Und in Compilern heißt es auch x86_64, weil es sonst zu Verwirrungen in den Dateinamen kommen könnte, nichtsdestotrotz heißt die Architektur x86-64!
Let the discussion begin. -- Lightkey 11:27, 4. Dez 2004 (CET)

---

Ich würde es halt gerne mit den Erfindern halten. AMD hat's erfunden und hat später gesagt, dass sie's gerne AMD64 nennen würden, damit jeder merkt, wer's erfunden hat. Debian hat seinen entsprechenden Port deswegen umbenannt. Dass die Kernel und Compiler jetzt unter x86-64 laufen, liegt wohl zum Teil daran, dass AMD mit seinem Wunsch etwas spät um die Ecke kam, als die Implementationen schon fertig waren. Ich finde, dass man der Firma diesen Gefallen trotzdem tun sollte. --Echoray 12:05, 4. Dez 2004 (CET)

---

Hah, ausgerechnet das wäre der einzige Grund meine Meinung zu ändern.
Ich habe einmal die Diskussion bei Debian nachgelesen, aber das hatte hauptsächlich den Grund, weil sie schon so viel Arbeit unter "amd64" gemacht hatten und weil es viele andere auch benutzen (deswegen muss es ja nicht unbedingt richtig sein).
Und die Argumentation, dass AMD gebeten hat es doch AMD64 zu nennen hatte mich damals erst recht darin bestärkt, dass sie es selbst noch als x86-64 sehen, aber als AMD64 vermarkten wollen, damit jeder weiß von wem es ist.
Dass sich AMD64 durchsetzen wird steht wohl außer Frage.
Viele nennen es immer noch x86-64, weil sie damit angefangen haben, GNU, Torvalds u. a., mich eingeschlossen, und ich werde wohl auch in Zukunft immer von x86-64 reden.
In der Debian Diskussion gab es auch einen Link zu dieser FAQ, in welcher steht, dass x86-64 jetzt AMD64 heißt. Wenn das der Erfinder von x86-64 sagt, sollte es auch übernommen werden.

So wie ich es sehe gibt es zwei oft vertretene Meinungen hierzu:

Die einen meinen x86-64 ist die korrekte Bezeichnung, da es vorher da war und AMD64 sei nur der Marketingname von AMD, wie EM64T der von intel ist.
Die anderen sind der Meinung, dass AMD es einfach umbenannt hat und es somit nun AMD64 heißt und intel das nur nicht anerkennen wollte und eine eigene Bezeichnung benutzt.

AMD ist nicht ganz unschuldig an dieser Situation und ich finde sie sollten endlich mal ein Machtwort sprechen, als Erfinder des Ganzen. -- Lightkey 14:39, 4. Dez 2004 (CET)

16bit fähig?

ich dachte am64 ist zwar noch 32bit, aber nicht 16bit fähig? --Theclaw 18:34, 10. Aug 2005 (CEST)

Er kann alles, was ein 32-Bit-Athlon kann. Also (16 Bit) Real Mode, 16 Bit Protected Mode, 32 Bit Protected Mode und 32 Bit System Management Mode. --RokerHRO 15:13, 13. Sep 2005 (CEST)

im 32 bit modus kann er noch 16 bit simulieren (vm86 modus), im longmode fehlt dieser vm86 modus; im longmode ist also nur 32 und 64 bit möglich

Jain. Wenn das Betriebssystem im Long Mode läuft, kann es 32- und 16-Bit Proteced-Mode-Programme im Rahmen des "Compatibility Mode" ausführen. RealMode-Programme (die unter 32-Bit-Protected-Mode-Betriebssystemen in einer VM86-Task ausgeführt werden können) werden im Long Mode nicht unterstützt. Auf einem 32-Bit-Betriebssystem funktionieren jedoch alle bisherigen Betriebsmodi.

Mit 16-bit-Daten kann die CPU in aber jedem Betriebsmodus arbeiten. Es ist fraglich, was Theclaw mit "16-bit-fähig" nun genau meinte. --RokerHRO 12:30, 22. Mai 2007 (CEST)

Fehler

"Diese Entscheidung zwang Intel das erste Mal in der Firmengeschichte, Technologie des Hauptkonkurrenten AMD in ihren eigenen Produkten anzubieten." Dies geschah bereits zum 2. mal. Intel übernahm AMDs 3D-Now!. -- 80.131.104.204 13:04, 13. Sep 2005 (CEST)

Das stimmt nicht, im Gegenteil hat AMD sogar ihren 3DNow!-Nachfolger FDP (oder war es FTP? Wäre nett, wenn das jemand herausfinden könnte, ich möchte nicht alle "Prozessorgeflüster" von 1999-2002 durchlesen) eingestellt und lizensiert stattdessen nur noch intels neue Befehlssätze. -- Lightkey 06:53, 19. Dez 2005 (CET)

Unterschied Befehlssatz <-> Mikroarchitektur

Der Artikel macht einen Fehler, indem er Befehlssatz und Mikroarchitektur zusammenwirft. "AMD64" ist in erster Linie ein Befehlsssatz (ISA), obwohl selbst AMD das ab und zu mit ihrer Mikroarchitektur durcheinander wirft. Der Befehlssatz ist aber vollkommen unabhängig von konkreten Prozessoren (wie z.B. Athlon 64, Turion 64, Sempron, Opteron etc.). Diese haben nur in sofern damit zu tun, dass sie eine Implementation dieser ISA sind. (Turin64 impliziert AMD64, aber nicht anders herum).

Man mache sich an folgender Aufstellung den Unterschied klar:

ISA: x86, Mikroarchitektur: Intel 386, Intel 486, Cyrix 5x86, Intel Pentium1, Cyrix 6x86, AMD K5, Rise mp6, Intel Pentium2, AMD K6(-2/3), Intel Pentium3, AMD K7 (Athlon, Duron etc), Intel Pentium4, Transmeta Cruoso, Via C3, Via C7 etc.

ISA: SPARC, Mikroarchitektur: Sun Ultrasparc IV, Fujitsu Sparc64, LSI Sparc, Sun Ultrasparc T1, Weitec Sparc etc.

ISA: ARM, Mikroarchitektur: StrongARM, XScale uvm.

ISA: AMD64 (x86-64): Mikroarchitektur: AMD K8 (Athlon64, Opteron etc), Intel Pentium4 (Nocona) (zukünftig: Intel Memron etc.)

Der englische Wikipedia-Artikel (http://en.wikipedia.org/wiki/AMD64) bekommt diesen Unterschied sehr gut hin.

Ja, das ist mir auch schon aufgefallen, deswegen hab ich auch den EM64T-Artikel "rausgesplittet". AMD nennt die CPU-Architektur AMD64, aber der Befehlssatz ist eigentlich x86-64.

Deswegen würd ich auch eher sagen, die ISA ist x86-64 und AMD64 bezeichnet die Implementation von x86-64 in die K8-Architektur. So wie EM64T die Implementation in die NetBurst-Architektur ist. Ein schwieriges Thema, weil AMD hier sehr schwammig mit den Bezeichnungen etc. umgeht.--Stickedy 23:08, 12. Feb 2006 (CET)

Performance im 64bit Modus

Im Artikel steht derzeit dieser Satz: "Während Desktopsoftware von der 64bit-Erweiterung kaum profitiert oder sogar gehemmt wird,... "

Ich denke, das gilt nicht für alle Desktop-Anwendungen. Ich denke Spiele, die wirklich für 64biit programmiert werden, können schon einen ordentlichen Leistungsgewinn bekommen. Das sieht man ja auch an der Play Station 3, dessen Prozessor (Cell) 128bit hat und das auch gut ausnutzen kann. Nur gibt es im Moment noch keine Spiele, die wirklcih für AMD64 programmiert wurden, bisher ´gibts nur Spiele, die nachher auf AMD64 gepatched wurden... 2006-03-16 10:57:33 MrBurns

Desktopsoftware beinhaltet keine Topspiele. Punkt. GuidoD 11:24, 16. Mär 2006 (CET)

Nein, eine Performancesteigerung ist eigentlich nicht zu erwarten. Die Ausführungseinheiten bzw. deren Geschwindigkeit ist in in 32 und 64 Bit ja identisch. Einzig der gößere addressierbare Speicher ist positiv für Speicherintensive Anwendungen. Und es kann noch Effekte geben, wenn sich die breiteren Register nutzen lassen bzw. nötig sind. Aber das dürfte in der Praxis so gut wie nicht vorkommen. Das sieht man ja auch im Linux-Bereich wo es schon viele x64-Software gibt.

Der Cell-Prozessor ist damit im übrigen auch gar nicht vergleichbar! --Stickedy 14:40, 16. Mär 2006 (CET)

Ääääähm, ich hoffe, dass das auch im Artikel steht, aber die Registerzahl und das damit sinnvolle register-basierte ABI bringen auch so einiges für Alltagsprogramme... der Effekt wird nur durch die breiteren Register teils aufgefressen, und ein paar Prozent Abweichung merkt keiner. Die Spiele setzen übrigens für Media-Operationen auf die SSE-Einheit, und die hat in beiden Varianten x86 / x64 die gleiche Registerbreite von 128bit, ist also sowieso plusminus Null. Worum ging es noch mal? GuidoD 15:13, 16. Mär 2006 (CET)

Man kann von 64bit sehr wohl Performance-Vorteile rausholen, z.B. in dem man 2 32bit-Zahlen zu eienr 64bittigen zusammenfasst bzw. berechnet man ja auch mit 32bit prozessoren manchmal 64bit Werte, die dafür halt in 2x32bit umgewandelt werden. Und ich kann mir nicht vorstellen, dass ein Spiel nur Floating Point Operationen verwendet und keine Integer-Operationen... -MrBurns 17:52, 16. Mär 2006 (CET)

Mit "beispielsweise" zu hantieren bringt gar nichts, da die x64 Verwendung sowohl Vor- als auch Nachteile bringt. So sind x64 Programme typisch 25%-30% größer als das identische Programm unter x86, und die zusätzlichen Speicherzugriffe können locker jeden Ausführungsvorteil auffressen. Folglich sind jene Bereich interessant, bei den häufig (!!!) jene vorteilhaften veränderten Merkmale gebraucht werden. Spiele gehören in der Regel nicht dazu - gepackte Darstellungen von x mal 32bit gehen wieder bestens auf die SSE (die normale ALU kann das nicht verarbeiten), und 64bit breite Integer sind selten - die werden weder bei Audio noch bei Grafik benötigt, und Gigabyte an Daten werden da auch nicht gerade benötigt. - Ich frag mich aber immer noch, ob das nicht schon längst in diesem Artikel steht? Eigentlich sollte es, oder man muss es halt in einem eigenen Abschnitt haarklein herausstellen. GuidoD 18:26, 16. Mär 2006 (CET)

Ich hab den letzten Abschnitt mal komplett überarbeitet - da scheinbar einige Interessierte mitlesen, kommentiert / korrigiert bitte. GuidoD 19:17, 16. Mär 2006 (CET)

Interwiki

SOrry, but this removing of en: interwiki wasn't wrong:

• There are articles: AMD64 and x86-64 in some languages.

Imagine, there are articles A and B. Somebody writes article A and add iw for A to other languages. But in some languages exist article B, which is about something close to A. And in one of langages somebody merges these articles to A, and B is redirect. And now the problem starts:

• Somebody writes B in his language and add interwiki to some langages. He hopes, that other links will add bot. But Bot goes through interwiki and find link to B, which is redirect to A. And both articles A and B exists in some languages. Bot don't know, which link to add.

So I selected for bot correct links and bot repaired these links in all languages.

But there is now possibility not to have incorrect interwiki and link to this merged language:

You can add interwiki like anchor: A#B.

But this must be done manually in one language first... 62.245.83.203 16:39, 11. Dez. 2006 (CET), cs:Wikipedista:JAn Dudík, owner of User:JAnDbot

Keine 80bit Floating-Point Zahlen in SSE

Im Artikel steht korrekterweise das Fehlen der transzendenten Funktionen in der SSE-Einheit, eine weitere Einschränkung ist jedoch auch die gegenüber der x87-FPU von 80 auf 64 bit reduzierte Breite der Floating-Point Register. Einige Anwendungen, die auf die erhöhte Genauigkeit Wert legen, haben damit Probleme, obwohl die 80bit FP-Register IMHO nur bei Intel&Co benutzt wurden und damit bei portablen Programmen keine Verwendung finden. Gleichwohl rechnet die x87-Einheit intern aber wohl immer mit 80bit, damit können sich dann Rundungsprobleme im Vergleich zur SSE-Einheit ergeben. Das sollte im Artikel (im Abschnitt Architektonisches) noch ergänzt werden. APritzel 17:16, 23. Jan. 2007 (CET)

Erledigt. :-) --RokerHRO 18:39, 23. Jan. 2007 (CET)

48 Bit oder 64 Bit Adresse?

Unter "Maximaler Arbeitsspeicher" steht was von 48 Bit virtueller Adresse mit Bezug auf die Pins zur CPU. 1. Was ist daran virtuell?

2. Ich dachte die Adresse hat jetzt 64 Bit?!?

Kann mir das jemand erklären? Konzales 17:09, 20. Mär. 2007 (CET)

Breite der Einträge in der MMU ? GuidoD 21:32, 20. Mär. 2007 (CET)

Virtuell ists deshalb, weil es nicht der physikalischen Speicheraddresse entspricht. Diese geht derzeit nur bis 40bit, kann aber leicht auf 48 bit erweitert werden. Aber das steht ja eigentlich eh schon im Artikel. -MrBurns 08:05, 21. Mär. 2007 (CET)

Ja, ok soweit klar. Aber 48 Bit und 64 Bit ist immer noch was anderes. Konzales 08:17, 21. Mär. 2007 (CET)

Die im Programm verwendeten (logischen) Adressen sind 64 Bit groß. Nur mit diesen wird innerhalb eines Programms gearbeitet. Diese logischen Adressen werden durch die Paging-Einheit über mehrstufige Page-Tabellen auf physische Adressen abgebildet. Diese physischen Adressen sind 52 Bit groß. Von diesen 52 Bit werden aber derzeit nur 40 Adressbits herausgeführt, da die derzeitigen CPUs nur 40 Adressleitungen haben. Es ist Aufgabe des Betriebssystems, die Pagingeinheit so zu programmieren, dass nur solche physischen Adressen gebildet werden, die auch eindeutig nach außen hin darstellbar sind. --RokerHRO 08:50, 21. Mär. 2007 (CET)

Wann brachte AMD 64 Bit CPUs raus?

Nehmt das doch bitte mit in den Artikel rein, hab auf die Schnelle nix gefunden, schade. --134.155.99.41 15:41, 11. Apr. 2007 (CEST)

Athlon 64 September 2003: K8#Modelldaten_Sockel_754, Opteron schon April 2003: AMD_Opteron#Sockel_940. -MrBurns 17:09, 11. Apr. 2007 (CEST)

Speicherverbrauch vs. Modus?

Nachdem ich jetzt also entgeistert erfahren habe, dass die 64 bit auf dem Desktop (außer evtl. für Spielkinder) praktisch nichts bringen - wer braucht schon mehr als 4 GB Arbeitsspeicher? (ich schätze mal: 99 % der Privaten haben nicht mal die; der Spielraum des 386-Standards wird bei Weitem noch nicht ausgeschöpft) -, muss ich jetzt auch noch entsetzt lesen, dass die Kapazität des physischen Speichers dabei wegen der Aufblähung des einzelnen Datums mit heißer Luft tendenziell halbiert wird (oder in der Praxis meinetwegen "nur" um 30 % verschwindet)! Echt supi, dieser Fortschritt!! Nun, wo kämen wir hin, wenn die Hersteller nicht wegen jedem dämlichen Gimmick am Verscherbeln neuer Hardware verdienen würden, da die alten STandards schlicht nicht mehr angeboten werden?

Meine Frage: Wie kann man um diesem galoppierenden Speicherschwund herumkommen? Sprich: Wenn man nun schon mal einen 64-Bitter hat: Kann man das System zwingen, die Progs ohne Speicherverschwendung zu handhaben?? Ich (mit meinen beschränkten Kenntnissen) ahne, dass das über die Beeinflussung der Prozessormodi geht - aber WAS KANN man da tun, und WIE MUSS man es tun?? (Bitte keine Expertenkenntnisse voraussetzen!) - Stahlrossritter, --213.102.107.230 03:01, 2. Jun. 2007 (CEST)

Alle x86 Variante sind rückwärtskompatibel, nicht nur 32bit sondern gar 16bit, also installiere einfach keine 64bit Betriebssysteme und Programme, und das war's. - zu dem langen Abschnitt, "wer braucht das schon", muss ich dich aber kurzsichtig schimpfen, denn jeder Computerprofi kennt die Geschichte, wo man mal behauptete "640KB" sind mehr als jemand ein Mensch brauchen würde. Wenige Jahre später war das hinfällig. Tatsächlich sind schon heute auf Servern auch für kleinere Büros schon längst 4 Gigabyte üblich (der Trend zu VM-Nutzung hat hier seinen Beitrag). - letztlich ist die Kompatibilität der x86 Betriebssystem so ausgerechnet, dass auch ein Mischbetrieb möglich. Ein 64bit Kern kann Programme in 32bit und 64bit ausführen, sodass man sich leicht entscheiden kann, welche Prgrammen man 64bit braucht und welche nicht. GuidoD 03:46, 2. Jun. 2007 (CEST)

32-Bit-Programme auf einem 64-Bit-Betriebssystem auszuführen, ist zwar durchaus möglich und manchmal auch sinnvoll. Aber wenn man auch 64-Bit-Programme ausführen will, braucht man alle Systembibliotheken doppelt, sowohl auf der Platte als auch im RAM. Und etwa KDE und seine Bibliotheken will man nicht doppelt im Speicher haben, denke ich mal. --RokerHRO 20:18, 2. Jun. 2007 (CEST)

Richtig, kann man aber auch zweierlei sehen - einerseits ist es doch so, wer Programme benutzt, die von 64bit profitieren, der hat ja auch meist genug Speicher eingebaut, damit wenigstens diese ordentlich laufen. Andererseits, wer regelmäßig 64bit Programme benutzt, da lohnt es sich scheinbar auch gleich komplett auf 64bit umzusteigen, dennoch hat man dann Mischbetrieb mit nur 32bittig vorliegenden (alten) Programmen. - Ob die Mehrresourcen des Mischbetrieb dann tatsächlich stören, naja also DOS und WIN16 Programme wurden bei Windows noch lange klaglos unterstützt. Und ich kenne einige harte Kerle, die dem ganzen Resourcenhunger trotzen und weiter unter DOS/WIN3.x arbeiten. Ist am Ende wohl doch ne Einstellungsfrage, ob man "mehr" für sinnvoll hält. ;-) GuidoD 21:10, 2. Jun. 2007 (CEST)

Naja, ich fahre auf einem meiner Rechner ein 64-Bit-System. Blöderweise gibt es einige Closed-Source-Programme (z.B. Sykpe) bisher nur in einer 32-Bit-Version. Deren Libraries muss man nun doppelt vorhalten. Schlimm ist das nicht, aber nervig. --RokerHRO 21:25, 2. Jun. 2007 (CEST)