Diskussion:Multi Media Extension

Unterschiede zw. MMX und MMX2

Könnte man auch mal erwähne was MMX von MMX2 unterscheidet wann es eingeführt wurde,... MMX2 taucht im Artikel überhaupt nicht auf. (nicht signierter Beitrag von 84.164.38.222 (Diskussion) 14:55, 6. Sep. 2010 (CEST))

Dieser Abschnitt kann archiviert werden. Moritzgedig (Diskussion) 12:32, 21. Okt. 2017 (CEST)

Einführung

Seit wann gibt es MMX? tsor 17:26, 28. Okt 2003 (CET)

Sie wurde mit dem Pentium-MMX eingeführt... Mehr weiß ich ad hoc auch nicht. --RokerHRO 10:14, 19. Mai 2004 (CEST)

Dieser Abschnitt kann archiviert werden. Moritzgedig (Diskussion) 12:32, 21. Okt. 2017 (CEST)

Registersatz

Wie wärs mit einer kleinen Grafik, und etwas Text, der die Aufteilung der 64-Bit-Register in 2 32er, 4 16er und 8 8-Bit-Register veranschaulicht? Inkl. "Saturation" und wofür man sowas braucht. Im ersten Absatz wird das zwar angerissen aber nicht näher erläutert. --RokerHRO 10:14, 19. Mai 2004 (CEST)

Name

Im Artikel IA-32 wird gesagt, dass MMX eigentlich Matrix Math Extensions heißt. Das sollte geprüft werden und falls es stimmt in den Artikel übernommen werden.

MMX bedeutet exakt gar nichts. Abkürzungen können in den USA nicht markenrechtlich geschützt werden. Das war der Grund um von i586 auf Pentium unzuschwenken, wie auch der Grund die Erweiterung mit einem Name auszurüsten der nach einer Abkürzung klingt, in den viel hineininterpretiert werden kann, der aber keine ist.

Dieser Abschnitt kann archiviert werden. Moritzgedig (Diskussion) 12:32, 21. Okt. 2017 (CEST)

DSP

Kann mann dieses Lemma nicht direkt verlinken, als daß man -vor allem als Laie- über zwei oder gar drei Begriffslärungsseiten geführt wird?

Dieser Abschnitt kann archiviert werden. Moritzgedig (Diskussion) 12:32, 21. Okt. 2017 (CEST)

FPU ?

MMX läuft doch generell in der FPU ab. Müsste man auch im Artikel besser klarmachen. Und außerdem schreiben, wie die evtl. antreffenden FPU-Befehle lahmgelegt werden, während MMX läuft. Gruß Boris Fernbacher 22:07, 20. Jun 2005 (CEST)

Kann ein Pentium mit MMX-Technologie bereits als 64-Prozessor betrachet werden?

In dem Artikel 64 Bit-Architektur wird die SIMD Technik als 64-Bit Architektur angegeben. Wenn diese Aussage stimmt, dann müßte ein Pentium MMX bereits ein 64-Bit Prozessor darstellen. Ist das der Fall? (Der vorstehende, nicht signierte Beitrag stammt von 85.178.29.53 (Diskussion • Beiträge) 00:25, 6. Jun. 2007) -- Uncle Pain 10:22, 6. Jun. 2007 (CEST)

Nein, denn die generelle Architektur der CPU ist nach wie vor 32 Bit: 32 Bit Adressbusbreite (und somit [ohne Tricks] max. 4 GiB adressierbarer Speicher), zumeist 32 Bit Registerbreite,... Nur weil die CPU auch einige Spezialbefehle unterstützt, die die (ohnehin für die FPU vorhandenen) 64-Bit-FP-Register nutzen, ist nicht die gesamte Architektur 64 Bit. Heutige CPUs bieten für SSE/SSE2/SSE3 sogar 128-Bit-Register, trotzdem sind sie keine 128-Bit-Prozessoren, denn ihre Architektur ist nach wie vor auf 32 (bzw. inzwischen 64 Bit) beschränkt. --Uncle Pain 10:22, 6. Jun. 2007 (CEST)

Ob eine CPU eine 16, 32 oder 64 Bit CPU ist, bestimmt ganz alleine die Datenbreite der ALU. Wie breit der Daten- oder Adressbus ist, ist egal. (nicht signierter Beitrag von 84.170.107.204 (Diskussion) )

Die Definition wirkt auf mich ziemlich engstirnig. Da könnte jemand daherkommen und ne CPU bauen mit 8-Bit-Adressbus, aber 128-Bit-ALU-Registern und das gälte nach deiner Definition dann als 128-Bit-CPU — obwohl von den 128 Bit gerade mal 8 für die Speicheradressierung genutzt werden könnten, eine überaus wichtige Einschränkung. Was ist denn gerade an der ALU so besonders, dass die Breite ihrer Register als Maß gelten sollen? Nur weil sie auch Pointerarithmetik macht? Wenn ja, müsste man nicht die Definition abändern, wenn die FPU mit ihren 64-, 80- oder 128-Bit-Registern auch Pointerarithmetik betreiben könnte? (bisschen weit hergeholt, da mir kein sinnvoller Anwendungsfall einfällt, aber mal hypothetisch) Was hat man denn davon, wenn die ALU-Adressregister groß sind, aber dadurch hinsichtlich Adressierbarkeit nichts gewonnen wird?

Andererseits wäre eine CPU mit 128-Bit-Adressbus und 8-Bit-Registern schon irgendwie ne 128-Bit-CPU... zwar ne verkrüppelte, da umständlich zu bedienen, aber man könnte dennoch 128 Bit Adressraum ansprechen, man müsste halt dazu die CPU so designen, dass Befehle mit Adressbezügen (Calls, Moves,...) ihre Pointer immer aus 16 (=128÷8) Registern beziehen... --Uncle Pain 10:25, 11. Mär. 2009 (CET)

Wenn die breite des Adressbus die Art der CPU bestimmen würde, dann wäre der 8086 und 8088 ein 20 Bit Rechner und der 80286er ein 24 Bit Rechner und das ist natürlich Unfug, da alle drei generell als 16 Bit Rechner gelten. Und der Grund dafür ist, weil das durch die ALU bestimmt ist. Die ALU ist nämlich die arithmetisch-logische Einheit (Arithmetik Logical Unit), also die Hauptrecheneinheit. Damit wird gerechnet und logische Operationen durchgeführt, also das, wofür eine CPU überhaupt da ist. --84.140.197.199 21:19, 29. Jul. 2023 (CEST)

Die ALU ist trotz 64 bittiger SIMD Einheit immer noch 32 Bit breit. Wenn die SIMD Einheit die Art der CPU bestimmen würde, dann würde das auch für die FPU gelten und dann wäre der 486DX bereits ein 80 Bit Rechner. Und das ist natürlich Unfug. --84.140.197.199 21:22, 29. Jul. 2023 (CEST)

Dieser Abschnitt kann archiviert werden. Moritzgedig (Diskussion) 12:32, 21. Okt. 2017 (CEST)

Begriffsklärung

Lt. Artikel heißt MMX "Multi Media Extension!" Gibts da einen Link zu einer offiziellen Aussage von Intel? Das gleiche für "Matrix Math Extensions" -- Quellenangabe, bitte? aths 21:29, 7. Jan. 2009 (CET)

Dieser Abschnitt kann archiviert werden. Moritzgedig (Diskussion) 12:32, 21. Okt. 2017 (CEST)

Datenformate

Die Formulierung "Intel spendiert, um mit MMX arbeiten zu können, dem Prozessor 57 weitere Befehle und führt vier neue Datenformate ein." könnte speziell für den Laien missverständlich sein. Die neu geschaffenen Datenformate Packed Byte, PackedWord, PackedDoubleWord, QuadWord sind ja nur eine andere Bezeichnung präexistierender Formate. Die neue Nomenklatur sollte wohl nur anzeigen, dass mit MMX nicht einzelne Daten/Zahlen sondern Datenfelder bearbeitet werden. Im Prinzip ist ja ein QuadWord nur ein 64-Bit-Feld welches man auch DoubleLongInt hätte nennen können. Ein ShortPackedWord ist prinzipiell ja nichts anderes als ein ShortPackedInteger. Das sollte man im Artikel entweder im Fließtext oder in einer Fußnote/Anmerkung zumindest kurz erwähnen. Reptilologe 17:41, 19. Feb. 2009 (CET)

Wenn du es so willst, dann sind alle Datenformate letzendlich eine diskrete Menge von Bytes. Ein Datenformat legt nicht udr die Größe, sondern auch die Interpretation fest - und ein QuadWord ist eine andere Interpretation eines DoubleLongInt, diese andere Interpretation ist aber das entscheidende. Diese ist der CPU wurscht - hilft aber dem Compiler oder Assembler mögliche Fehler zu erkennen.

Gescheiterte Lesenswert-Kandidatur 5.-12. März 2009

Die Multi Media Extension (kurz MMX) ist eine Anfang 1997 von Intel auf den Markt gebrachte Rechnerarchitektur (SIMD), die es erlaubte, große, meist mit den selben Befehlen zu bearbeitende (parallelisierbare) Datenmengen, wie sie z. B. bei der Verarbeitung von Video, Audio und Bildern anfallen, schneller zu verarbeiten. Ursprünglich stand das Kürzel MMX für Matrix Math Extensions, wurde allerdings von Intel aus marketingtechnischen Gründen in Multi Media Extension umbenannt. MMX verwendete keine physikalisch neuen Prozessorregister, sondern funktionierte die Register des mathematischen Koprozessors (FPU) um. Intel entwarf für MMX 57 neue Prozessor-Befehle und führte vier neue Datenformate ein. Ein Hauptvorteil von MMX war die Unterstützung von Saturationsarithmetik. MMX wurde nach seiner Einführung von der Softwareindustrie nur zögerlich unterstützt und war schon nach drei Jahren durch Intels eigene Fortentwicklungen SSE und AMDs 3DNow! überholt. Benchmarks zu seiner Performance wiesen eine große Bandbreite auf.

Den Artikel bitte in der aktuellen Version (hier) beurteilen.

Eigentlich sollte jeder Mensch im Rahmen der Allgemeinbildung über ein so wichtiges Thema wie MMX informiert sein. Schließlich steckte das ab 1997 jahrelang in sehr vielen Geräten als Technologie drin. Der Artikel ist so allgemeinverständlich gehalten wie es bei dem Thema ohne Verlust der Wissenschaftlichkeit möglich ist. (Für den Neueinsteiger in den Bereich kann man zur Vorbereitung auf den MMX-Artikel auch empfehlen: Wikibook Assembler-Programmierung für x86-Prozessoren)

Die Kernpunkte der MMX-Technologie werden m.M. nach im Artikel tiefschürfend genug behandelt:

• Das neue Konzept der parallelen Datenverarbeitung unter SIMD
• Verwendung/Missbrauch der FPU-Register für MMX-Anwendungen samt der Unterschiede zur FPU-Verwendung
• Das "Umschalten" zwischen MMX- und FPU-Anwendungen im Detail
• Eine vollständige und ausführliche Beschreibung des maschinensprachlichen Befehlsvorrats für MMX samt Regeln für Operanden
• Aritmethische Modelle (Saturation-Mode und Wrap-around-Mode) von MMX
• Der Rest des Artikels behandelt Exceptions, CPU`s mit MMX, und die Umsetzung in Software, die Unterstützung von MMX durch Sprachen/Compiler, Performance-Untersuchungen, und einen Ausblick über MMX hinaus

Auf eine Durchreferenzierung jeder Aussage wurde verzichtet. Belege zum Befehlsvorrat stehen bei Bedarf alle in Intel: Intel Architecture Software Developer's Manual, Volume 2 - Instruction Set.

Als Hauptautor  Neutral.

Reptilologe 15:26, 5. Mär. 2009 (CET)

Abwartend - nicht nur, dass ich finde, das was hinter MMX steht, gehört nicht zum Allgemeinwissen. Diese Datei ist vermutlich entweder eine URV (wegen der Lizenz) oder kein offizielles Logo für MMX. -- defchris (Diskussion • Beiträge) 15:33, 5. Mär. 2009 (CET)

@Defchris:

Man kann natürlich verschiedener Meinung sein, ob Computertechnolgie heute zum Algemeinwissen gehören sollte oder nicht.

Falls diese Datei (hier) aus der englischen Wikipedia wegen URV hier nicht verwendbar sein sollte, kann man das natürlich ganz schnell löschen. Dies Logo transportiert kaum inhaltliche Information, und ist für den Artikel auch nicht essentiel.

Reptilologe 15:46, 5. Mär. 2009 (CET)

 Kontra, die Einleitung ist eine einzige Katastrophe. Der tolle Satz: "Benchmarks zu seiner Performance weisen eine große Bandbreite auf" rundet die Einleitung wirklich genial ab. Bitte in einem Review sprachlich generalüberholen lassen. --Succu 17:08, 5. Mär. 2009 (CET)

@Succu: Benchmarks sind wirklich ein sehr ungenaues Messinstrument. Das kannst du in der Literatur nachlesen. Speziell für MMX gibt es unterschiedlichste Messungen zwischen 5 % Performance-Vorteil bis zu 200 % Vorteil. Speziell Intel oder Microsoft-Messungen sind mit Vorsicht zu genießen. Dass Benchmarks von vielen Faktoren abhängig sind, zeigt auch der Artikel referenziert in Absatz 7. Leistung. Deshalb ist der Satz der Einleitung "Benchmarks zu seiner Performance weisen eine große Bandbreite auf" vollkommen richtig formuliert. Speziell der Abschnitt Leistung ist deshalb im Artikel mit 5-6 Referenzen zu verschiedenen Performance-Leistungen belegt. Du hättest den Artikel doch etwas weiter lesen sollen. Dass deiner Meinung nach die Einleitung eine "einzige Katastrophe" sein soll, habe ich sachlich leider nicht verstanden. Könntest du das noch näher begründen ? Reptilologe 17:21, 5. Mär. 2009 (CET)

Ich weiß was Benchmarks sind und wie man sie manipuliert. Der kritisierte Satz ist eine Nullaussage, also locker entbehrlich. Weitere Beispiele für ungenügende Formulierungen: "auf heutigen" oder "überholt". Das Lemma ist "Multi Media Extension" und nicht "MMX™", muss also fett ausgezeichnet werden. --Succu 17:53, 5. Mär. 2009 (CET)

Der kritisierte Satz mag in deiner Sicht eine Nullaussage sein. Für den Normalleser ist das aber eine wichtige Info darüber wie man Benchmarks zu werten hat. Deine Kritik an Formulierungen wie "auf heutigen" oder "überholt" kann ich teilweise nachvollziehen. Ändere das doch bitte an den entsprechenden Stellen im Artikel. In Bezug auf die Zukunft (dass MMX mit SSE 1,2,3,4 usw. erweitert wurde), ist der Ausdruck "überholt" aber auch nicht ganz falsch. Der Ausdruck "auf heutigen" stammt nicht von mir. Ändere das halt, wenn du es für ungeschickt erachtest. Zu dem Problem "MMX™" fett, oder nicht, oder irgendwie anders kann ich nichts weiteres sagen. Solche "Scheinprobleme" interessieren mich als Programmierer nicht. Es geht eigentlich darum wie eine Sache funktioniert, und nicht darum wie sie dann mal benannt wurde. MMX war ein neues IT-Konzept mit einigen damals neuen Prozessor-Befehlen und einer anderen Verwendung/Philosophie existierender Register. Das wird im Artiklel dargelegt. Es geht darum, und um nichts weiter ! Reptilologe 18:05, 5. Mär. 2009 (CET)

MMX-Befehlssatz war sicher damals in den Zeiten des Multimedia-Hypes eine interessanter technologischer Ansatz, der in die nachfolgenden Prozessorgenerationen (wenn ich mich nicht irre) integriert wurde, aber gewiss kein "IT-Konzept". Wenn dich als Softwareentwickler solche "Kleinigkeiten" nicht kratzen, dann ist das deine persönliche Einstellung, aber erwarte bitte nicht, das dir das niemand bei einer Lesenswert-Kandiatur "um die Ohren haut". --Succu 18:58, 5. Mär. 2009 (CET)

Sorry; der Artikel beschreibt doch explizit, dass MMX schon bald (in deiner Formulierung der Multimedia-Hype) ein veraltetes Konzept war. Lies dazu einfach den Artikelabschnitt Nach MMX . Mir ist es als Programmierer vollkommen klar, dass MMX nach 1-2 Jahren nur noch ein historisches Modell war. Das wird auch im Artikel an vielen Stellen deutlich. Niemand hat etwas anderes gesagt. Deine Kritik ist also deswegen absolut unverständlich. Lies bitte den Artikel auch mal bis zum Ende durch. Natürlich waren die MMX-Gedanken nicht sehr revolutionär gegenüber dem späteren SSE. Im Jahr 1997 war es aber ein neues "IT-Konzept" für Grafikanwendungen. Reptilologe 19:36, 5. Mär. 2009 (CET)

Die Einleitung und der gesamte Artikel ist überwiegend im Präsens verfasst. Meinst du nicht das da ein unbedarfter, nur flüchtig nach Informationen suchender Leser mit den ersten paar Sätzen ein völlig falsche Bild erhält? Dir als "Programmierer" ist klar das MMX "nur noch ein historisches Modell" ist. Dann hast du schon mindestens zwei falsche Weltbilder. Eines von deinem Berufsbild als Softwareingenieur und eines was die historischen Bedeutung von MMX für die Weiterentwicklung der Prozessorkerne betrifft. Ganz zu schweigen davon, was ein lesenswerter Artikel in der Wikipedia leisten muß. Sieh es als Benchmark-Test an. Ich beende unseren Dialog mal vorerst an dieser Stelle. --Succu 20:04, 5. Mär. 2009 (CET)

Ich verstehe deine Kritik nicht. Dem "unbedarften Leser" wird doch schon in der Einleitung klar gesagt: "MMX wurde nach seiner Einführung von der Softwareindustrie nur zögerlich unterstützt und war schon nach drei Jahren durch Intels eigene Fortentwicklungen SSE und AMDs 3DNow! überholt." Deine Kritik am Präsens ist auch nicht ganz begründet. MMX und sein Befehlsvorrat wurde ja nicht irgendwann offiziell abgeschaft. Die Befehle waren in nachfolgenden Konzepten wie z.B. SSE2 weiterhin möglich. Obwohl man natürlich dann die mächtigeren Möglichkeiten von SSE nutzte. Ein Spiel welches 1998 mit MMX-Instruktionen erstellt wurde, läuft ja auch 5 Jahre später auf Systemen welche die SSE-Technik anwenden. Einen MS-DOS Befehl muss man auch nicht in der Vergangenheitsform beschreiben. Du kannst ja anstatt den Windows-Explorer zu verwenden unter Windows ein DOS-Fenster aufmachen, und wie früher "dir c:" eintippen. Reptilologe 10:33, 6. Mär. 2009 (CET)

In bestimmten Situationen hilft bis heute nur ein "dir c:" o.ä. auf Kommandozeilenebene. Aber es wäre schön wenn wir nicht länger aneinander vorbeireden würden. MMX war eine Erweiterung des X86-Befehlsatzes die vom Endanwender sowohl besondere Hard- wie Softwaretechnische Voraussetzungen verlangte (wiedermal aus dem Gedächtnis heraus). Die Integration in spätere Intel-Prozessoren ist eine andere Geschichte. Kurz MMX ist Geschichte, also Vergangenheitform. DOS ist eine Voodoo-Puppe: Einfach nicht tot zu kriegen. --Succu 20:03, 6. Mär. 2009 (CET)

MMX Befehle sind auch unter SSE weiterhin einsetzbar. Intel hat bei SSE sogar ein paar neue MMX-Befehle kreiert. Es wird am Anfang im Artikel klar gemacht, dass es eine alte Technik von 1997 ist. Aber die Befehle kann man auf einem alten Rechner immer noch einsetzen. Warum solte dann im Artikel stehen: "Der Befehl MOVD ermöglichte die Operation xy" ? Wenn den Befehl jemand bei einem alten PC heute einsetzt, dann funktionert er noch. Es heißt nicht er funktionierte. Dennoch habe ich jetzt zumindest mal die Einleitung deiner Argumentation folgend in die Vergangenheitsform gesetzt. Reptilologe 08:05, 7. Mär. 2009 (CET)

• contra - die Einleitung ist ein no go; wenn ich als Laie bereits in der Einleitung 20 Buchstabenkombis wie SIMD, FPU, AltiVec, SSE anklicken und dort dann andere (meist ebenso unverständliche) Artikel lesen muss, um einen diffusen Begriff davon zu bekommen, über was ich da gerade nachschlage, dann ist entweder an dem Artikel was verkehrt (Stichwort OMA bzw. Barrierefreiheit) oder ich bin zu blöd. Ich gehe von ersterem aus ohne zweiteres auszuschliessen: Als Nachschlage-Artikel unbrauchbar. -- Achim Raschka 19:59, 5. Mär. 2009 (CET)

@Achim: Begriffe wie SIMD, FPU sind bei dem Thema unumgänglich. Es ist leider unmöglich, einen Begriff wie MMX der viel mit dem Prozessor und Maschinensprache zu tun hat, ohne alle Fachbegriffe zu erklären. Um alles im Details zu verstehen ist Kenntnis von Assembler nötig. Tut mir leid Achim; MMX-Grundlagen sind halt keine Hochsprache wie unserer Basic aus dem Schulunterricht. Der Unterschied zwischen FPU- und MMX-Anwendungen liegt im Detail. Das kann man nicht in allgemeinverständlichen Schlagworten darstellen. Die Alternative für die Einleitung wäre: "MMX ist eine Computertechnologie für schnelle Spiele. Es fetzt gut. Aber SSE ist inzwischen cooler." Das wäre OMA-tauglich ! Reptilologe 20:17, 5. Mär. 2009 (CET)

Vielleicht würde es ja bereits reichen, wenn man statt SIMD einen erklärenden Halbsatz a la eine Prozessurarchitektur, die für XY optimiert ist (SIMD) schreibt. Wenn ich um in einem Nachschlagewerk einen Begriff nachschlagen möchte, eh schon alles wissen muss, um auch nur die Einleitung zu verstehen, taucht imho das Nachschlagewerk halt nicht - der untenstehende Artikel kandidiert ja schließlich auch nicht mit der Einleitung Carcharodon carcharias ist der einzige valide Vertreter des monotypischen Taxons Carcharodon, der aufgrund seines arttypischen Migrationsverhaltens weltweit sympatrisch mit anderen Elasmobranchiern anzutreffen ist. -- Achim Raschka 20:30, 5. Mär. 2009 (CET)

@Mark und Achim: Eure Kritik ist sehr zielführend. Danke für euer Pro und Contra und für das Interesse und die Einsicht in wohl nicht ganz einfache EDV-Gebiete. Vielleicht ist die Einleitung von mir wirklich etwas unverständlich formuliert. Der Unterschied zwischen einer "normalen" CPU-Anwendung und MMX mit den Anforderungen an für Grafik optimierte Operationen wird im Kapitel I "Anforderungen von Multimediaanwendungen" m.M nach allerdings doch recht allgemeinverständlich dargestellt.

Aber vielleicht habt ihr recht: Es sollten evtl. einige Aussagen aus diesem Kapitel I in die Einleitung ohne Fachtermini eingebaut/vorgezogen, und einfacher formuliert werden. Eine gewisse "Fachblindheit" und Detailverliebtheit von mir möchte ich bei diesem Artikel nicht ausschließen. Meine Heimatsprache war halt viele Jahre nicht Deutsch, sondern Assembler, C, C++, Visual Basic, und anderes. Reptilologe 22:19, 5. Mär. 2009 (CET)

Die Einleitung wurde etwas allgemeinverständlicher umformuliert. Nun müsste es auch ohne Anklicken von Links (FPU, Register, parallelisierbar, Integer, etc.) verständlich sein. Reptilologe 11:40, 6. Mär. 2009 (CET)

Danke, die Einleitung lässt mich jetzt nicht mehr im Regen stehen - den restlichen Text werde ich am Wochenende lesen. -- Achim Raschka 12:02, 6. Mär. 2009 (CET)

Bleibe neutral - der Artikel ist für mich weiterhin in weiten Teilen Computerfach-Bla und hilft mir nicht beim Verständnis des Lemmas. Wenn die Computerexperten einen solchen Artikel als lesenswert befinden dürfen sie es tun -- Achim Raschka 22:11, 8. Mär. 2009 (CET)

•  Pro, Artikel hat sich inzwischen im Hinblick auf Allgemeinverständlichkeit deutlich verbessert. -- MARK 19:08, 7. Mär. 2009 (CET)

•  Pro Detaillierte Darstellung der Technologie. Gute stukturierte Erklärung des Befehlssatzes. Mit aussagekräftigen Grafiken versehen. Weitaus besser als der Artikel der engl. WP. Umsetzung in Compilern und Software fehlt nicht. 88.67.136.84 04:55, 10. Mär. 2009 (CET)
•  Pro Wer mit MMX überhaupt nichts anfangen kann, der sollte den Artikel eigentlich nicht lesen. Viele Normalsterbliche interessieren sich für solche Dinge kaum. Für Computerfreaks wie mich ist er allerdings eine echte Bereicherung. -- Astrobeamer ^{Chefredaktion} 23:41, 10. Mär. 2009 (CET)
•  Pro Full Ack zu Benutzer:Astrobeamer. Sehr umfassend informativ. 94.216.100.164 08:29, 11. Mär. 2009 (CET)
•  Pro Informativ und verständlich für am Sachgebiet Interessierte... VG--Magister 08:51, 11. Mär. 2009 (CET)

Anmerkung: Hübsche Fließbandarbeit an Pros. Mittlerweile ist die Einleitung deutlich verständlicher geworden, was erfreulich ist, da sie ja auch für Nicht-Computerfreaks gedacht ist (OMA). Ich hätte gern mein Contra zurückgezogen, wenn Reptilologe die von ihm erstellten Graphiken durch in einem vernünftigen Format (z.B. PNG) ersetzt hätte, worum ich ihn auf meiner Disk gebeten hatte. Leider ohne Erfolg, was bei mir den schalen Beigeschmack einer URV hinterläßt. Pardon. Ein Normalsterblicher --Succu 17:14, 11. Mär. 2009 (CET)

•  Kontra Nach einigen längeren Recherchen über die eingefügten Grafiken habe ich meine Meinung geändert. Das ändert aber nichts daran, dass ich den Artikel wie oben beschrieben für sinnvoll halte. -- Astrobeamer ^{Chefredaktion} 20:57, 11. Mär. 2009 (CET)

 Kontra In mindestens einem Punkt haben die Autoren die Technik nur unvollständig verstanden (oder sind vielleicht nicht in der Lage, sie darzustellen). Abschnitt: "Einsatz in Betriebssystemen". Multi-Tasking-Betriebssysteme bewältigen immer die Aufgabe, alle Prozessorregister, die ein Task benutzen darf, bei einem Taskwechsel taskspezifisch abzuspeichern und bei Rückkehr zu diesem Task wiederherzustellen. Das ist sozusagen ihre Kernaufgabe. Das gilt natürlich auch für FPU-Register. Gerade weil MMX HW-mäßig die FPU-Register zweckentfremdet, wäre also zu erwarten, dass ein Multitasking-Betriebssystem, das die FPU-Einheit unterstützt, voll kompatibel zu MMX ist. Der Abschnitt behauptet nun das Gegenteil und bleibt eine schlüssige Erklärung schuldig. In mindestens diesem Punkt ist der Artikel fachlich nicht korrekt. Weiter als bis dahin habe ich den Artikel nicht gelesen, weil ohne fachliche Korrektheit ein Artikel nicht als "lesenswert" eingestuft werden darf. Giro Diskussion 23:05, 11. Mär. 2009 (CET)

Schon der erste Satz ist nicht richtig formuliert. Die Multi Media Extension (kurz MMX) ist eine Anfang 1997 von Intel auf den Markt gebrachte Rechnerarchitektur (SIMD), die es erlaubte, große, meist mit den selben Befehlen zu bearbeitende (parallelisierbare) Datenmengen, wie sie z. B. bei der Verarbeitung von Video, Audio und Bildern anfallen, schneller zu verarbeiten. Erstens ist MMX keine „Rechnerarchitektur“, sondern einfach eine Erweiterung des Befehlssatzes. Allerdings eine Erweiterung des Befehlssatzes, die die Gleitkommaeinheit (FPU) als zweites Rechenwerk benutzt. Diese Gleitkommaeinheit kann gleichzeitig mit dem Prozessor arbeiten und unabhängig von ihm, obwohl sie auf demselben Chip integriert ist (anfangs gab es 2-Chip-Lösungen). Die Erweiterung des Befehlssatzes ermöglicht es, diese Fähigkeit der FP, gleichzeitig mit dem Prozessor zu arbeiten, mit einer Reihe neuer Befehle bzw. Adressierungsarten zu nutzen. Diese neuen Befehle sind speziell auf Rechenoperationen ausgelegt, wie sie bei Grafik und Audio auftauchen, wobei große Datenmengen bearbeitet werden müssen. Bei entsprechender Nutzung der neuen Befehle können diese Rechenaufgaben von der FPU schneller ausgeführt werden als vom Prozessor. Während diese Berechnungen in der FPU erfolgen, kann der Prozessor gleichzeitig auch andere Aufgaben weiterbearbeiten. Es geht also zweitens nicht um "parallelisierbare Datenmengen", sondern um die Möglichkeit, rechenintensive Aufgaben an die FPU auszulagern. Trivial ist natürlich, dass Prozessor und FPU nicht gleichzeitig auf denselben Daten herumarbeiten dürfen, während sie gleichzeitig arbeiten. Das muß aber nicht in die Einleitung, schon garnicht in den ersten Satz. Soweit mal eine Anregung zur Verbesserung der Oma-Tauglichkeit der Einleitung. Giro Diskussion 03:23, 12. Mär. 2009 (CET)

Der Artikel ist in dieser Version mit 4  Pro und 3  Kontra nicht lesenswert. --MEWRS Zigarre gefällig? 14:58, 12. Mär. 2009 (CET)

Tatsächlich sind es nur 2 Prostimmen, die Stimmen von 88.67.136.84 und 94.216.100.164 stammen mit sehr hoher Wahrscheinlichkeit vom Hauptautor Benutzer:Reptilologe, eine der Stimmen wurde schon vor dessen Sperre am 11. März abgegeben. Siehe auch das gelöschte Gepöbel von 88.67.130.174. Schon bemerkenswert, mit welchen Mitteln hier sogenannte Qualitätsautoren arbeiten. --Hozro 09:46, 18. Mär. 2009 (CET)

Dieser Abschnitt kann archiviert werden. Moritzgedig (Diskussion) 12:32, 21. Okt. 2017 (CEST)

Register, nochmal

AFAIK benutzt MMX intern schon andere Register, da die MMX-Einheit eine andere Einheit als die x87-FPU-Einheit ist. Nur nach außen wurden die MMX-Register in die FPU-Register gemappt, damit keine Änderungen im Betriebssystem (für den Save-Context beim Taskewechsel) nötig sind. Wie schon richtig im Artikel steht, ist dieses Mapping bei neueren CPUs abschaltbar, so dass dann eine Unterstützung im Betriebssystem notwendig wird. Oder? --RokerHRO (Diskussion) 12:45, 23. Okt. 2014 (CEST)

Die Aussage mit den FPU Registern suggeriert zudem, dass es sich auch um FP Zahlen handelt und diese von der FPU verarbeitet werden. --Moritzgedig (Diskussion) 12:33, 21. Okt. 2017 (CEST)

Es würde schon Sinn machen die FPU Register mehrfach zu benutzen, denn die Register brauchen sehr viele Transistoren. Dass es bei neueren CPUs abschaltbar ist, ließe sich dadurch erklären, dass bei modernen CPUs die paar Transistoren auch nicht mehr so teuer sind. Du kannst aber gerne mal recherchieren, warum man für MMX die FPU Register verwendet hat.

--84.140.197.199 21:26, 29. Jul. 2023 (CEST)

Defekte Weblinks

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Die folgenden Weblinks wurden von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieser Fehler finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://infopad.eecs.berkeley.edu/CIC/announce/1997/pent233-mmx.html
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Netzwerk-Fehler (6) andere Artikel, gleiche Domainhttp://giftbot.dwl.invalid/http://infopad.eecs.berkeley.edu/CIC/announce/1997/pent233-mmx.html
• https://eprints.kfupm.edu.sa/29557/1/29557.pdf
  • Im Jahr 2012 bereits defekt gewesen.http://giftbot.dwl.invalid/https://eprints.kfupm.edu.sa/29557/1/29557.pdf
• http://www.fh-zwickau.de/doc/prmo/mmxtutor/text/index.htmhttp://giftbot.dwl.invalid/http://www.fh-zwickau.de/doc/prmo/mmxtutor/text/index.htm
• http://www.codeplay.com/technology/vectorc.html
  • Vielleicht ist eine archivierte Version geeignet: archive.org * webcitation.orghttp://giftbot.dwl.invalid/http://www.codeplay.com/technology/vectorc.html
• http://user.cs.tu-berlin.de/~nurgle/mmx/mmx.html
  • Im Jahr 2012 bereits defekt gewesen.http://giftbot.dwl.invalid/http://user.cs.tu-berlin.de/~nurgle/mmx/mmx.html

– GiftBot (Diskussion) 03:28, 27. Nov. 2015 (CET)

Befehl Mem32, MMX

Im Artikel steht:

„Eine Angabe wie
Befehl Mem32, MMX
Befehl MMX, Reg32
Befehl Reg32, MMX
würde z. B. besagen, dass die Operation (Befehl) von einem MMX-Register zu einem 32-Bit-Allzweckregister, von einem 32-Bit-Allzweckregister zu einem MMX-Register und umgekehrt möglich ist.“

Muss es bei Mem32 nicht heißen, dass eine Operation von einem MMX-Register zu einer Speicheradresse möglich ist? --84.140.197.199 21:10, 29. Jul. 2023 (CEST)