Diskussion:AMD64/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:AMD64/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:AMD64/Archiv/1#Thema_1

Solaris 9 und 10

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)

x86-64

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)

Die einzige wirkliche Beschleunigung im 64bit Modus ggü. dem 32bit Modus auf einem Core2 Duo habe ich mit POV-Ray festgestellt (also FPU-lastige Sachen), ansonsten konnte ich (mit bzip2, 7zip, xz) keine nennenswerten Beschleunigungen feststellen. Die "Vorteile" des größeren Speichers per Programm sind anwendungsspezifisch, ich wollte fast sagen: akademisch... --80.152.226.20 16:31, 23. Jun. 2012 (CEST)

Das könnte aber auch dran liegen, dass Povray auf x86 die x87-FPU-Befehle benutzt, auf x86-64 dagegen SSE, was deutlich flotter ist. Oder das die neuesten Optimierungen in Povray 3.7 nur noch für 64-Bit-Plattformen gemacht werden. --RokerHRO (Diskussion) 09:17, 30. Jun. 2012 (CEST)

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)

Der Satz ... Außerdem beherrscht die SSE-Einheit nur 64-Bit-Gleitkommaarithmetik, während die x86-FPU-Einheit intern mit 80-Bit-Gleitkommaarithmetik arbeitet.

macht für mich überhaupt keinen Sinn. Selbst für wissenschaftliche hohe Genauigkeiten sind 64-Bit vollkommend ausreichend, sonst hätten Wissenschaftler längst ein 128 Bit (was kompletter Größenwahn darstellt!!!) eingeführt. Ich würde empfehlen den Satz anders zu schreiben. Speziell das oben genannte Problem der Portablität von Programm mit 80-Bit FP-Registernutzung, wäre wesentlich einleuchtender als die angebliche 64-Bit "Ungenauigkeit".

Eigentlich haben SSE-Einheiten sogar 128bit-Register, können also prinzipiell auch mit 128bit Genauigkeit rechnen. Nur verwendet man die 128bit in der Praxis eher um mehrere 32bit- oder 64bit-Operationen gleichzeitig durchzuführen. --MrBurns 08:52, 22. Jul. 2007 (CEST)

Ob jemand nun 80- oder 128-bit-Gleitkommazahlen braucht oder nicht, ist irrelevant, wenn es um die reinen Fakten geht, dass eben die SSE-Einheit nicht mit 80- oder 128-bit-Gleitkommazahlen rechnen kann. Es ist die Aufgabe einer Enzyklopädie, Fakten wiederzugeben, aber nicht, sie zu bewerten.

Im Übrigen wurde im 64bit-Modus das Alignment für long double von 10 auf 16 Bytes, also 128 Bit, angehoben, es werden also bei long double derzeit stets 6 Bytes nutzlos vergeudet. Es existieren aber die optionalen C99-Datentypen __int128 und __float128, welche ebenfalls 16 Bytes benötigen. Der 80-bit long double ist außerdem insofern kompatibel zum geplanten IEEE-754r-128bit-Gleitkommadatentyp, da beide den gleichen Wertebereich für den Exponenten benutzen, nur ist die Mantisse beim 80-bit-Datentyp halt kürzer.

Wenn du also keine 80- oder 128-bit-Gleitkommadatentypen brauchst, ist das deine Sache. Deswegen aber zu unterstellen, sie seien generell überflüssig oder "Größenwahn" mit 3 Ausrufezeichen, ist ein wenig vermessen, finde ich. --RokerHRO 12:52, 22. Jul. 2007 (CEST)

2^64~1,84E+19. Also eine Ungenauigkeit von ~10^(-19) reicht locker für alle wissenschaftliche Berechnungen, eine größere Genauigkeit bräuchte man höchstens für unsinnige mathematische Berechnungen, wenn man z.B. mit Pi auf 38 Stellen genau rechnet, was sich aber auch ohne 128bit-Zahlen berechnen lässt, nur halt viel langsamer. Also für alle Berchnungen, die eien Anwendung ind er realen Welt haben und auch für alle Grafikberechnungen reichen 64bit locker aus. Und wenn man 6 Bytes verschwendet, dann liegt das wohl daran, dass es einfacher ist, Register zu verwenden, deren Biitzahl einer Zweierpotenz entspricht. Es stimmt schon, dass es die Aufgabe einer Enzyklopädie ist, Fakten zusammenzufassen, aber nur, wenn sie relevant sind und wenn man etwas nicht berechnen kann, das keiner braucht ist das irrelevant. Und außerdem gibt es ja auch Operationen, wo man mehrere 32bit- oder 64bit-Werte zu einem Wert mit 128bit zusammenfassen kann. --MrBurns 09:03, 29. Jan. 2009 (CET)

Das ist eine äußerst gewagte Behauptung. Bei den Grafikberechnungen gebe ich Dir zwar Recht, da ist es meist egal, wenn beispielsweise durch die 64 Bit eine ganz leicht abweichende Farbe herauskommt. Im Bereich des wissenschaftlichen Rechnens habe ich allerdings bei mehreren BOINC-Projekten erlebt, dass es auf jedes Bit Genauigkeit ankommt, das man bekommen kann. Das war dann der Fall, wenn es in der Natur der Anwendung lag, dass sich mehrfache Rundungsfehler gnadenlos multiplizieren. Mit "mehrfach" ist hier "wirklich mehrfach" gemeint, also beispielsweise ein paar Millionen aufeinander folgende Multiplikationen. --Echoray 09:17, 29. Jan. 2009 (CET)

Die ganz leicht abweichende Farbe ist vor allem deshalb irrelvant, weil diese Abweichung eh nicht dargestellt werden kann, da die Ausgabe mit max. 24bit, in seltenen Fällen vielleicht noch mit 30bit erfolgt. --MrBurns 09:28, 29. Jan. 2009 (CET)

Nachtrag: mit Alphakanal sinds bis zu 32bit, aber das ändert am Grundsatz nichts, dass die Präzision der Ausgabe viel geringer ist als 64bit. --MrBurns 16:21, 29. Jan. 2009 (CET)

Es gibt ja nicht nur grafische Ausgaben. Bisweilen braucht man auch die exakten Zahlen, bis aufs letzte Bit, wie Echoray ja auch schon schrob. --RokerHRO 00:20, 30. Jan. 2009 (CET)

Es gibt durchaus auch im Grafikbereich Anwendungen für Genauigkeiten über 32Bit. Sicher kann ein Monitor nur 24Bit darstellen (einen Alphakanal kann man nämlich auf dem Monitor nicht darstellen - es bleibt bei einer Kombi aus rot, grün und blau). Nicht umsonst gibts es bei Direct3D Textur-Formate mit bis zu 32Bit pro Farbkanal (also 32*4 = 128Bit). Jene braucht man sicher nicht für normale Anwendungsfälle aber in bestimmten Situationen kanns hilfreich sein. Bei nichtgrafischen Anwendungen freuen sich viele numerische Algorithmen, wenn die Genauigkeit hoch ist, da es durchaus zu großen Abweichungen kommen kann - auch schon bei kleinen Ungenauigkeiten am Anfang. Ums kurz zu machen: Wenn man von bestimmten wissenschaftlichen Szenarien keine Ahnung hat, dann sollte man sich hüten über selbige Aussagen zu treffen - sowas geht meistens in die Hose... Achso und die Präteritumsform von schreiben ist und bleibt schrieb (Wikitionary). -- Michaelvs 22:17, 4. Okt. 2009 (CEST)

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 48 Bit groß. Von diesen 48 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)

Nachtrag: Siehe nebenstehende Grafik, die die Umsetzung von linearen 64-Bit-Adressen auf physische Adressen veranschaulicht: Die Bits 48 bis 63 sind die "Vorzeichenerweiterung" von Bit 47, somit stets alle 0 oder alle 1. --RokerHRO 13:46, 2. Okt. 2009 (CEST)

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.

Übrigens wird der Virtual 8086 Mode zum Ausführen von DOS-Programmen im 64-Bit-Modus nicht mehr unterstützt. Aber dafür gibt es ja Dosbox, der das alles in Software nachbildet :-) --RokerHRO 21:26, 2. Jun. 2007 (CEST)

Dosbox ist aber sau langsam, damit rennt z.B. Duke Nukem 3D auf meinem Athlon XP 3200+ System nicht mal in der niedrigsten Auflösung in einer brauchbaren Geschwindigkeit. Mit einem Athlon 64 wirds zwar etwas schneller sein, aber sicher nicht ausreichend, um jedes DOS-Programm in einer ordentlichen geschwindigkeit (also in etwa so schnell wie auf einem pentium mit 2000 MHz) rennen haben zu können oder jedes DOS-Spiel in maximaler Grafikqualität zu spielen. Wenn man bedenkt, dass die neuesten DOS-Spiele schon 10 jahre alt sind ist das schon arm. Aber es gibt trotzdem eine Methode, die DOS-Programme in ansprechender Qualität rennen zu lassen, ohne ein zweites Windows kaufen zu müssen: man nimmt eine bootbare Diskette mit DOS und rebooted von dieser. Natürlich muß man die Autoexec.bat und Config.sys so schreiben, um den Erweiterungsspeicher nutzen zu können und ausreichend viel konventionellen Speicher frei zu machen. Und man muß natürlich auch die erforderlichen Programme (HIMEM.SYS und EMM386.EXE) auf der Diskette haben. Und man braucht eine FAT16 oder FAT32 Partition (letzteres geht nur, wnen man DOS 7.1 oder höher verwendet, also das, was bei Win 98/Me dabei war).

Was die 4GB-Grenze angeht: einige Spiele brauchen heutzutage schon 2GB, um mit maximlarr Performance zu rennen, also wirds nimmer allzu lange dauern, bis auch für Desktops die 4GB Grenze relevant wird (unter Win XP sinds ja praktisch nur ~3GB, weil der Rest des Addressbereichs ist nicht nutzbar, sondern für systemzwecke Reserviert ist). -MrBurns 04:49, 3. Jun. 2007 (CEST)

Unter Windows XP (32 bit) hat eine Applikation grundsätzlich max. 2GB zur Verfügung. Man kann den Wert zwar auf 3 erhöhen, aber sowas wird in der Regel nicht gemacht (und bei der Defaultinstall so und so nicht). Also auch 4GB im System bringt einem einzelnen schwerlastigen Programm rein gar nichts. Ihm wird bei spätestens 2GB der Hahn abgedreht.

Die Grenze von 2GB/Programm kann man aber evenetuell umgehen, indem man das Programm auf mehrere Prozesse aufteilt. -MrBurns 11:02, 15. Jun. 2007 (CEST)

Speichersegmentierung 2.0 ? ;-) ... GuidoD 11:14, 15. Jun. 2007 (CEST)

Länge der Pipeline

In den Artikeln anderer Prozessoren wird auch die länge der Pipeline genannt. Wäre es nicht gut diese auch hier zu ergänzen?

Hier geht es doch gar nicht um einen Prozessor, sondern um den Befehlssatz bzw. die Architektur AMD64. Die Pipelinelänge ist abhängig vom Prozessor und nicht vom Befehlssatz. --Uncle Pain 15:25, 8. Jul. 2007 (CEST)

Platform-Unterschiede?

auf der Suche nach HW-Platform-Unterschieden (i386, AMD64, ...) vermisse ich eine 'Oberschicht der einzelnen Artikel.

Die Detail-Genauigkeit lässt mich fragen, ob die Hersteller direkt die Seiten 'pflegen .

UND DABEI WIRD JEDER VERWEIS AUF ANDERE EXISTENZEN VERMIEDEN?

Gruss abonino -- 212.60.51.92 15:19, 1. Jan. 2008 (CET)

Was genau vermisst du denn im Artikel? --RokerHRO 14:06, 2. Jan. 2008 (CET)

AMD64 früh verfügabar?

Am Ende des Abschnittes "Intel 64 – AMD64 aus dem Hause Intel" hiess es, dass sich für AMD64 und gegen IA64 entschied weil: "Die Wahl fiel wegen der früheren Verfügbarkeit auf die AMD-Erweiterung."
Anfangs der 90er-Jahre gab es den ziemlich weit verbreiten Workstations- und Server-Prozessor DEC-Alpha. Der war damals schon eine volle 64Bit-Arichdektur. AMD ist also eher sehr spät mit der Verfügbarkeit von 64Bit-CPU's.
Es war wohl eher die Rückwärts-Kompatibilität zu i368 und die Preise die MS Entscheid beeinflussten. -- Thomei08 21:01, 6. Sep. 2009 (CEST)

Außerdem waren die Alpha-CPUs nicht von Intel. --MrBurns 01:21, 3. Okt. 2009 (CEST)

Und IA64 war früher verfügbar als AMD64 131.234.40.123 (14:44, 6. Jan. 2012 (CET), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Architektur

In dem Abschnitt Architektur steht das AMD mit AMD64 auch den Syscall-Befehl eingeführt hat, was so etwas missverständlich ist. Denn den Befehl gibt es seit K6-Zeiten! (nicht signierter Beitrag von 92.76.108.252 (Diskussion) 13:54, 20. Sep. 2010 (CEST))

Speicherverbrauch

Zitat: Alle Adresswerte sind 64 Bit statt 32 Bit breit. Ihre Speicherung verbraucht daher im RAM und in den Caches doppelt soviel Platz und bei Bewegungen zwischen RAM und CPU müssen somit doppelt so viele Bytes bewegt werden

Bedeutet das, wenn einer 12GB Ram im PC besitzt, dass er bei 64bit nur noch mit 6GB arbeitet?

--Avene 11:18, 28. Dez. 2010 (CET)

Praktisch bedeutet das, Zitat: "im Vergleich zum 32-Bit-Programm etwa 25 bis 30 Prozent größer sind", rechnet man das von 12GB@32Bit/100% per Dreisatz zu 12GB@64Bit/130% so erhält man 9,23GB@64Bit als Vergleichswert. Nimmt man Speicher als Hinweis für Geschwindigkeit, ist es aber wieder egal, da 64-Bit Programme durch andere Maßnahmen (vor allem Registerzahl) wieder schneller sind, daher in den meisten Fällen keinerlei Unterschied bei einem Umstieg 32-Bit -> 64-Bit zu bemerken ist. GuidoD 11:46, 28. Dez. 2010 (CET)

Praktisch bedeutet es vor allem, dass man bei einem 32-Bit-Betriebssystem eh nur 2,5 bis 3 GB RAM nutzen kann, außer man macht einige Klimmzüge, sowohl im Betriebssystem (PAE) wie auch im Anwendungsprogramm (unter Windows z.B. mit AWE). Von den 12 GB RAM hat man also eh nicht wirklich was. :-/ --RokerHRO 14:45, 28. Dez. 2010 (CET)

Bei der Speicher-Aserei heutzutage ist es eh' egal, wo die Laufzeiten verschwinden. Performance ist heutzutage zwar mehr denn je ein Thema, nur keiner weiss, wo er anfangen soll, weil zu speicherintensives ueberfluessiges Zeugs geladen wird. Ich weiss gar nicht, wieso allerlei Programme (selbst bunte Bilder: siehe Xerox Star) frueher ein paar Kilobyte benötigten und heute in MegaBytes gerechnet werden müssen... Und 64bit verbrauchen nur dann mehr Laufzeit, wenn die Datenbusse die alten 32bit-Busse bleiben, die internen Caches auch nur 32bit reden und dabei recht klein sind und die Look-ahead-Logik auf der Strecke geblieben ist. Kann ich mir bei diesem "wie im Artikel erwähnt" Prozessor gar nicht vorstellen. AMD scheint mir 'ne ganz gute Schmiede zu sein. Abgesehen davon ist nicht jeder Befehl 64bit-orientiert. Da hat GuidoD schon recht. Vor 40 Jahre hat IBM mal eine Studie zur Lokalität von Programmen gestartet, und siehe da: 90 Prozent aller Instruktionen waren lokal auf ein kleines Segment beschränkt. Und nur 10 Prozent der Instruktionen wurden angewendet. Daraufhin gab's dann die RISC-Prozessoren. Folge daraus ist hier: Lokalität, daher bei Umschaltung auf 64bit lediglich 10 bis 30 Prozent Mehrverbrauch an Speicher, sofern dann 64bit Programme verwendet werden. Die Aserei bleibt jedoch erhalten durch nie genutzte Routinen in den geladenen Bibliotheken... -anonymous, 46.115.38.51 07:49, 21. Okt. 2012 (CEST)

was ist eine "Aserei"?--81.13.179.105 16:57, 31. Dez. 2014 (CET)

Man kann es Specherverschwendung nennen (ndt asen) aber da Speicher nunmal billig ist, wird die Softwareentwicklung damit schlichtweg günstiger. Mussten früher einige komplexe Probleme mit guten Algorithmen gelöst werden, so kann man heute einfach noch n Speicherriegel reinwerfen - als Beispiel, gibt es heute immer noch Texteditoren, die die gesamte Datei in den Hauptspeicher laden, als hätte es Memory Mapping oder stückweises Laden mit Edit-Gap (wie beim Emacs) nie gegeben. Zurück zu 64-Bit: gerade die Speichereinblendung macht eben auch die Bearbeitung von riesigen Dateien erst effizient - so ein einzelnes Programm, dass sich für ein paar Bilder viel Speicher greift, muss jedoch nicht auf 64bit umgestellt werden. Wenn aber auch alle Bibliotheken schon 64-bit sind (da kommt Großteil der Aserei ja her), baut man eben alle Programme so. Und belegt zumindest auf der Platte eben 30% mehr. Aber: auch Plattenplatz ist billig. GuidoD 17:53, 31. Dez. 2014 (CET)

unscharf-unklar

"Neuerdings wird das Kürzel x64 von Microsoft und einigen Fachpublikationen für dieses erweiterte Programmiermodell verwendet"

Was heisst 'neuerdings' in einem Nachschlagewerk? Bitte präzisieren. Die Situation rund um den Bezeichnungskrieg und die marketingstrategischen Namenswahl sollten in einem separaten Abschnitt historisch gewürdigt werden (timeline), um im Hauptartikel zur Klarheit lediglich die aktuell gültige Bezeichnung- am besten tabellarisch aufzuzeigen. --81.13.179.105 16:54, 31. Dez. 2014 (CET) (cosy-ch)

265 TiB

Wie kommt man darauf? Wie rechnet man das aus? (nicht signierter Beitrag von Dnvuma (Diskussion | Beiträge) 11:57, 29. Aug. 2015 (CEST))

2 hoch 48 Byte wegen den gegenwärtig 48 nutzbaren Adresspins. --Echoray (Diskussion) 18:30, 29. Aug. 2015 (CEST)

Es sind auch Funktionen entfernt worden

Im 64-Bit Modus funktioniert z. B. die Berechnung mit BCD Zahlen nicht mehr. Diese Operationen sind schon seit den 1990er nicht mehr relevant und wurden nun endlich entfernt. Erwähnenswert wäre das, da meines Wissens nach bisher immer nur neue Funktionen dazukamen aber nie welche entfernt wurden, wegen der Abwärtskompatibilität! (nicht signierter Beitrag von 79.250.247.63 (Diskussion) 15:10 Uhr, 6. September 2012)

Darf mit Quelle gerne in den Artikel. --79.224.239.135 18:19, 10. Sep. 2012 (CEST)

Quelle: AMD Programmers Manual, z.B. Vol 3 (http://support.amd.com/us/Processor_TechDocs/24594_APM_v3.pdf)

Folgende Assemblerbefehle sind im 64-Bit-Modus nicht mehr erlaubt:

• AAA, AAD, AAM, DAS, AAS, LED, LDS, APRL, INTO, PUSHA, POPA, PUSHAD, POPAD, BOUND,
• SYSENTER, SYSEXIT
• die Segmentregister-Präfixe CS:, DS:, ES:, SS:
• die PUSH und POP-Befehle mit den Segmentregistern CS,DS,ES,SS als Parameter,
• die 1-Byte-Opcodes zum INCrementieren und DECrementieren der General-Purpose Register EAX,ECX,EDX,EBX, ESP, EBP, ESI, EDI

(Ohne Anspruch auf Vollständigkeit) --RokerHRO (Diskussion) 13:44, 17. Sep. 2012 (CEST)

Bezüglich sysenter und sysexit gibt es übrigens IIRC eine Kontroverse zwischen AMD und Intel. Einer von beiden erlaubt nämlich durchaus die Verwendung dieser Opcodes im 64-bit Modus und gas assembliert sie auch (im Gegensatz zu aaa etc.). --21:48, 17. Sep. 2012 (CEST) (nicht signierter Beitrag von FUZxxl (Diskussion | Beiträge) 21:48, 17. Sep. 2012‎)

Obwohl es nicht wirklich schlimm ist, wenn die BCD-Rechnerei aus dem Prozessor verschwunden ist. Die Banken fahren dafür sowieso Mainframes und kein Spielzeug, und letztlich war das lediglich eine Reverenz an die Mainframes mit dem seltsamen Hintergedanken, solche ablösen zu können. Die Geschichte hat das nun alles überholt und ich kann nur hoffen, dass nicht zu viele Programmierer ihre PC-Finanzprogramme in COBOL gebaut haben. Das würde hier denn deutlich Nachbearbeitung in Sachen Emulation bedeuten... Trotzdem ist ein interessanter Aspekt, dass auf Abwärtskompatilibität verzichtet wurde... -anonymous, 46.115.38.51 08:00, 21. Okt. 2012 (CEST)

Nö. BCD ist verschwunden, weils niemand gebraucht hat. Es ist zigmal schneller, in binär zu rechnen und dann nur bei Ein- und Ausgabe in Dezimalzahlen zu wandeln. Und wer wirklich eine BCD-Arithmetik braucht (ich wüsste nicht, wofür), ist mit Lookup-Tabellen (die komplett in den L1-Cache passen) immernoch fixer als mit diesen BCD-Befehlen. --RokerHRO (Diskussion) 09:44, 21. Okt. 2012 (CEST)

BCD spielt nach wie vor eine große Rolle - auch wenn du nicht weißt wofür. BCD-Arithmetik verbindet gigantische Wertebereiche mit extremster Genauigkeit und hat in Forschung und Wissenschaft nach wie vor eine Bedeutung. Allerdings war man auf eine CPU-Unterstützung nie angewiesen. 79.212.132.90 01:13, 30. Mär. 2015 (CEST)

Die Wissenschaft verwendet eher en:Decimal floating point, allerdings unterstützen nur wenige Prozessoren das IEEE Format in Hardware. Die neuere Finanzmathematik definiert übrigens auch keine Fixed Decimal mehr, die sich schnell mal auf BCDs abbilden ließen - unter Fix Protocol Data Types steht oft "Note the number of decimal places may vary". Eine echte Gleitkommadarstellung ist damit verpflichtend. GuidoD 03:52, 30. Mär. 2015 (CEST)

Mit decimal floating Point rechnet man schon deshalb nicht, weil diese Zahlen das Problem aller Gleitkommaformate haben, den Wertebereich nicht lückenloos abzudecken. Sei eine hypothetisches Gleitkommaformat mit der Mantissenlänge zwei gegeben und der Exponentenlänge drei gegeben, so sind die Zahlen 98, 99 und 100 darstellbar. Die nächste darstellbare Zahl ist die 110 - nicht darstellbar sind 101 - 109. Diese Zahlen liegen jedoch im Wertebereich. Kein Forschunginstitut kann es sich leisten bei Berechnungen als Ergebniss oder Zwischenergebnis auf eine solche Abdeckungslücke zu stoßen. Dieses hypoothetische Format kann bei einem dezimal basierenden System Werte zwischen 99*10^3 = +-99000 und 99*10-3 = +-0,0099 darstellen. Dies sind insgeamt mögliche 10.000.000 Zahlen - davon sind 10.000 auch durch das hypothetische Format darstellbar.

Die Alternativen sind zum einen die erwähnten BCD-Zahlen, weitere sind BigInt und die Festkommazahlen. Beide haben ebenfalls einen begrenzten Wertebereich, decken diesen aber vollständig ab. Das Verlassen des Wertebereichs und somit die Erkennung einer fehlerhaften Berechnung ist jedoch erkennbar.

Wenn Sie die Anforderung haben, die Kreiszahl PI auf 100 quadrillionen Stellen nach dem Komma ausrechnen zu wollen, werden Sie sich mit der BCD-Arithmetik anfreunden müssen. 79.212.159.91 10:48, 23. Okt. 2015 (CEST)

Bitte WP:DS beachten. Wer, wo und warum BCD verwendet oder nicht, ist nicht Gegenstand des Artikels. Die BCD-Befehle sind im 64-Bit-Modus entfernt worden. Vielleicht findet man ja irgendwo eine Quelle von AMD nach dem Warum, bis dahin bleibt das nur Spekulation.

Aber wenn ich mir den Code anschaue, den gcc oder clang im 32-Bit-Modus generieren, kann ich da nirgends etwas finden, dass diese Compiler die BCD-Befehle irgendwo im erzeugten Maschinencode einbauen. Darum meine Aussage, dass die anscheinend auch nie jemand vermisst hat. Wenn du meinst, dass die BCD-Maschinenbefehle auf x86 irgendwo in relevanter Software benutzt werden, bist du in der Beweispflicht. Aber … bitte nicht in diesem Artikel, hier gehört das nicht hin. --RokerHRO (Diskussion) 11:48, 23. Okt. 2015 (CEST)

Veraltet

Hallo, der Artikel ist teilweise stark veraltet. Beispiel: Neuerdings wird das Kürzel x64 von Microsoft und einigen Fachpublikationen für dieses erweiterte Programmiermodell verwendet. ist von 2005! -- Live Long and Prosper Motte001 • Diskussion • 19:19, 7. Apr. 2016 (CEST)

Warum änderst du es nicht einfach? :-) --RokerHRO (Diskussion) 08:18, 8. Apr. 2016 (CEST)

Ganz einfach: Der Artikel ist nicht zu 100% mein Fachgebiet. Ich kann natürlich einiges ändern, aber von manchem weiß ich einfach nicht, ob das veraltet ist oder nicht -- Live Long and Prosper Motte001 • Diskussion • 21:55, 8. Apr. 2016 (CEST)

War doch gar nicht schlecht. Kleine Änderungen bringen den Artikel ja auch schon voran!   --RokerHRO (Diskussion) 22:25, 8. Apr. 2016 (CEST)

Schreibweise x86

@PerfektesChaos: Wieso ×86? Original heißt es x86 mit einem regulären kleinen x! (Betrifft diese Bearbeitung.)

‣Andreas•⚖ 19:49, 21. Feb. 2017 (CET)

Sorry for confusion.

Das ist normalerweise Typografie für 2x3=4 – die hatte ich eigentlich zurückgesetzt, aber sie war vor dem Abspeichern wieder angesprungen: Spezial:Diff/162880398

LG --PerfektesChaos 20:09, 21. Feb. 2017 (CET)

Kein Problem. Danke. ‣Andreas•⚖ 20:30, 21. Feb. 2017 (CET)