Explicitly Parallel Instruction Computing - Versionsgeschichte

Pemu am 13. Juni 2019 um 21:36 Uhr

2019-06-13T21:36:51Z

JamesP: fixed typo

2017-03-03T14:06:55Z

fixed typo

← Nächstältere Version		Version vom 3. März 2017, 16:06 Uhr
Zeile 79:		Zeile 79:
	st b, gr5		st b, gr5

	In vielen Fällen genügt es aber nicht, einen Befehl um einen oder zwei Befehle vorzuverlegen, da der Unterschied zwischen der Dynamik des ~~Prozessor~~ und dem Speicher zu groß ist. Die Verarbeitung der Daten muss warten, bis die Daten geladen wurden. Das Laden der Daten soll darum so weit vorverlegt werden, dass kein Warten notwendig ist.		In vielen Fällen genügt es aber nicht, einen Befehl um einen oder zwei Befehle vorzuverlegen, da der Unterschied zwischen der Dynamik des Prozessors und dem Speicher zu groß ist. Die Verarbeitung der Daten muss warten, bis die Daten geladen wurden. Das Laden der Daten soll darum so weit vorverlegt werden, dass kein Warten notwendig ist.

	Wird ein Ladebefehl wie im untenstehenden Beispiel über eine Verzweigung vorverlegt, so spricht man von einer '''{{lang\|en\|Control Speculation}}.''' Tritt beim Laden ein Fehler auf, so soll dieser nicht behandelt werden, da man ja noch nicht weiß, ob man die Daten überhaupt benötigt. Das Laden erfolgt spekulativ. Bevor die Daten verarbeitet werden, muss aber geprüft werden, ob beim Laden ein Fehler aufgetreten ist und behoben werden muss. Die zweite Art der Spekulation ist die '''{{lang\|en\|Data Speculation}}.''' Die große Anzahl von Arbeitsregistern erlaubt es viele Datenelemente in Registern zu halten. Um zu verhindern, dass beim Laden auf Daten gewartet werden muss, werden die benötigten Daten frühzeitig in Register geladen. Die folgende Befehlsfolge zeigt ein Beispiel für einen normalen Load. Der Befehl <code>add gr5=gr2,gr7</code> kann erst durchgeführt werden, wenn die Daten aus dem Speicher in <code>gr2</code> geladen wurden.		Wird ein Ladebefehl wie im untenstehenden Beispiel über eine Verzweigung vorverlegt, so spricht man von einer '''{{lang\|en\|Control Speculation}}.''' Tritt beim Laden ein Fehler auf, so soll dieser nicht behandelt werden, da man ja noch nicht weiß, ob man die Daten überhaupt benötigt. Das Laden erfolgt spekulativ. Bevor die Daten verarbeitet werden, muss aber geprüft werden, ob beim Laden ein Fehler aufgetreten ist und behoben werden muss. Die zweite Art der Spekulation ist die '''{{lang\|en\|Data Speculation}}.''' Die große Anzahl von Arbeitsregistern erlaubt es viele Datenelemente in Registern zu halten. Um zu verhindern, dass beim Laden auf Daten gewartet werden muss, werden die benötigten Daten frühzeitig in Register geladen. Die folgende Befehlsfolge zeigt ein Beispiel für einen normalen Load. Der Befehl <code>add gr5=gr2,gr7</code> kann erst durchgeführt werden, wenn die Daten aus dem Speicher in <code>gr2</code> geladen wurden.

Y2kbug: VLIW verlinkt

2017-02-12T18:42:24Z

VLIW verlinkt

← Nächstältere Version		Version vom 12. Februar 2017, 20:42 Uhr
Zeile 14:		Zeile 14:
	Die wichtigsten Merkmale dieser Befehlssatzarchitektur sind:		Die wichtigsten Merkmale dieser Befehlssatzarchitektur sind:
	* Statische Befehlsgruppierung: Der Compiler legt fest, welche Befehle parallel abgearbeitet werden können. Dadurch wird der Prozessor wesentlich einfacher (Pentium 4 mit 42 Millionen Transistorfunktionen, Itanium mit 25 Millionen Transistorfunktionen).		* Statische Befehlsgruppierung: Der Compiler legt fest, welche Befehle parallel abgearbeitet werden können. Dadurch wird der Prozessor wesentlich einfacher (Pentium 4 mit 42 Millionen Transistorfunktionen, Itanium mit 25 Millionen Transistorfunktionen).
	* VLIW-Architektur: Der Prozessor erhält {{lang\|en\|very long instruction words}}, welche mehrere Befehle und die Aussage enthalten, auf welcher Einheit des Prozessors der Befehl auszuführen ist. Bei der IA-64 werden drei Befehle in ein VLIW gepackt.		* [[Very Long Instruction Word\|VLIW]]-Architektur: Der Prozessor erhält {{lang\|en\|very long instruction words}}, welche mehrere Befehle und die Aussage enthalten, auf welcher Einheit des Prozessors der Befehl auszuführen ist. Bei der IA-64 werden drei Befehle in ein VLIW gepackt.
	* {{lang\|en\|predication}}: Unter {{lang\|en\|Predication}} (Aussage, Behauptung) versteht man die bedingte Ausführung von Befehlen ohne Verwendung von Sprungbefehlen.		* {{lang\|en\|predication}}: Unter {{lang\|en\|Predication}} (Aussage, Behauptung) versteht man die bedingte Ausführung von Befehlen ohne Verwendung von Sprungbefehlen.
	* {{lang\|en\|speculation}}: Damit im Befehlsablauf nicht auf Daten gewartet werden muss, können Daten zu einem frühen Zeitpunkt spekulativ geladen und bearbeitet werden.		* {{lang\|en\|speculation}}: Damit im Befehlsablauf nicht auf Daten gewartet werden muss, können Daten zu einem frühen Zeitpunkt spekulativ geladen und bearbeitet werden.

Trustable: typo

2017-01-20T20:17:08Z

typo

← Nächstältere Version		Version vom 20. Januar 2017, 22:17 Uhr
Zeile 30:		Zeile 30:
	Das Optimierungsziel eines gegebenen EPIC-Programmes ist, die Anzahl der nötigen ''{{lang\|en\|instruction groups}}'' zu minimieren, also die durchschnittliche Anzahl der Instruktionen pro ''{{lang\|en\|instruction group}}'' zu erhöhen.		Das Optimierungsziel eines gegebenen EPIC-Programmes ist, die Anzahl der nötigen ''{{lang\|en\|instruction groups}}'' zu minimieren, also die durchschnittliche Anzahl der Instruktionen pro ''{{lang\|en\|instruction group}}'' zu erhöhen.

	Dabei gibt es Ausnahmen (beim Beispiel IA-64). Zum Beispiel müssen ''{{lang\|en\|Exceptions}},'' die durch eine frühe Instruktion einer Gruppe ausgelöst werden immer so ausgeführt werden, als ob die späteren Instruktionen einer Gruppe gar nicht ausgeführt worden sind. Beliebige Instruktionen können aber spekulativ bereits ausgeführt worden sein, deren Ergebnis wird beim Auftauchen einer {{lang\|en\|Exception}} einer früheren Instruktion verworfen. Der Prozessor muss also den Anschein erwecken, dass die Instruktionen einer Gruppe in Reihenfolge ausgeführt wurden. Andere Ausnahmen betreffen spezielle Instruktionen, die per ~~Definition~~ am Anfang oder Ende einer ''{{lang\|en\|instruction group}}'' vorkommen müssen.		Dabei gibt es Ausnahmen (beim Beispiel IA-64). Zum Beispiel müssen ''{{lang\|en\|Exceptions}},'' die durch eine frühe Instruktion einer Gruppe ausgelöst werden immer so ausgeführt werden, als ob die späteren Instruktionen einer Gruppe gar nicht ausgeführt worden sind. Beliebige Instruktionen können aber spekulativ bereits ausgeführt worden sein, deren Ergebnis wird beim Auftauchen einer {{lang\|en\|Exception}} einer früheren Instruktion verworfen. Der Prozessor muss also den Anschein erwecken, dass die Instruktionen einer Gruppe in Reihenfolge ausgeführt wurden. Andere Ausnahmen betreffen spezielle Instruktionen, die per definition am Anfang oder Ende einer ''{{lang\|en\|instruction group}}'' vorkommen müssen.

	== Eigenschaften ==		== Eigenschaften ==

TheRandomIP: +Belege fehlen

2016-08-08T10:26:26Z

+Belege fehlen

← Nächstältere Version		Version vom 8. August 2016, 12:26 Uhr
Zeile 1:		Zeile 1:
			{{Belege fehlen\|2=Der gesamte Artikel}}

	Das '''Explicitly Parallel Instruction Computing''' ('''EPIC''') bezeichnet ein [[Programmierparadigma]] einer [[Befehlssatzarchitektur]] ({{EnS\|''Instruction Set Architecture''}}, kurz ''ISA'') und der Verarbeitungsstruktur einer Familie von [[Mikroprozessor]]en, z. B. [[Itanium]]. Bei der [[Programmierung]] von EPIC-CPUs wird die Parallelisierung der Befehle eines Instruktionsstromes explizit vorgenommen. Die ISA hat Eigenschaften, die die explizite [[Parallele Programmierung\|Parallelisierung]] unterstützen, während eine herkömmliche ISA von einer sequentiellen Abarbeitung der Befehle ausgeht. Ein Programm, das in einer Nicht-EPIC [[Maschinensprache]] vorliegt, kann auch parallelisiert werden, aber es ist bei der Ausführung eine komplexe [[Logikgatter\|Logik]] notwendig um parallel ausführbare Instruktionen zu identifizieren, da das Befehlsformat keine Aussagen über parallelisierbare Instruktionen macht. Eine EPIC-[[Hauptprozessor\|CPU]] arbeitet nach dem Prinzip der [[in-order execution\|in-order Execution]], im Gegensatz zur out-of-order execution der [[Superskalarität\|superskalaren]] CPUs.		Das '''Explicitly Parallel Instruction Computing''' ('''EPIC''') bezeichnet ein [[Programmierparadigma]] einer [[Befehlssatzarchitektur]] ({{EnS\|''Instruction Set Architecture''}}, kurz ''ISA'') und der Verarbeitungsstruktur einer Familie von [[Mikroprozessor]]en, z. B. [[Itanium]]. Bei der [[Programmierung]] von EPIC-CPUs wird die Parallelisierung der Befehle eines Instruktionsstromes explizit vorgenommen. Die ISA hat Eigenschaften, die die explizite [[Parallele Programmierung\|Parallelisierung]] unterstützen, während eine herkömmliche ISA von einer sequentiellen Abarbeitung der Befehle ausgeht. Ein Programm, das in einer Nicht-EPIC [[Maschinensprache]] vorliegt, kann auch parallelisiert werden, aber es ist bei der Ausführung eine komplexe [[Logikgatter\|Logik]] notwendig um parallel ausführbare Instruktionen zu identifizieren, da das Befehlsformat keine Aussagen über parallelisierbare Instruktionen macht. Eine EPIC-[[Hauptprozessor\|CPU]] arbeitet nach dem Prinzip der [[in-order execution\|in-order Execution]], im Gegensatz zur out-of-order execution der [[Superskalarität\|superskalaren]] CPUs.

78.35.15.42 am 16. Dezember 2015 um 10:18 Uhr

2015-12-16T10:18:25Z

← Nächstältere Version		Version vom 16. Dezember 2015, 12:18 Uhr
Zeile 7:		Zeile 7:
	* den Stromverbrauch, die Verlustleistung und damit Wärmeabgabe zu reduzieren.		* den Stromverbrauch, die Verlustleistung und damit Wärmeabgabe zu reduzieren.

	Die {{lang\|en\|out-of-order execution}} ist teilweise auch aus dem Zwang zur Rückwärtskompatibilität zu älteren Prozessoren entstanden. Da das Befehlsformat eines älteren Prozessors weiterhin unterstützt werden musste, konnten Verbesserungen zur parallelen Ausführung nur unter der Haube geschehen. Prinzipiell ist es aber möglich den [[Compiler]] mit dieser Aufgabe zu betrauen und in den meisten Fällen ist ein Compiler für diese Aufgabe besser geeignet, da er mehr Zeit auf die Optimierung aufwenden kann und Zugriff auf mehr Informationen über den Programmfluss hat.		Die {{lang\|en\|out-of-order execution}} ist teilweise auch aus dem Zwang zur Rückwärtskompatibilität zu älteren Prozessoren entstanden. Da das Befehlsformat eines älteren Prozessors weiterhin unterstützt werden musste, konnten Verbesserungen zur parallelen Ausführung nur unter der Haube geschehen. Prinzipiell ist es aber möglich, den [[Compiler]] mit dieser Aufgabe zu betrauen, und in den meisten Fällen ist ein Compiler für diese Aufgabe besser geeignet, da er mehr Zeit auf die Optimierung aufwenden kann und Zugriff auf mehr Informationen über den Programmfluss hat.

	== Merkmale ==		== Merkmale ==

Emdee: /* Predication */ typo

2015-12-14T09:54:30Z

Predication: typo

← Nächstältere Version		Version vom 14. Dezember 2015, 11:54 Uhr
Zeile 52:		Zeile 52:
	; NOP		; NOP

	Die Predicate-Register können mit Compare-Befehlen gesetzt werden. Der folgende Compare-Befehl testet die Register <code>gr10</code> und <code>gr11</code> auf ~~Gleichhiet~~. Das Predicate-Register <code>p1</code> wird mit Resultat, das Register <code>p2</code> mit dessen Negation geladen.		Die Predicate-Register können mit Compare-Befehlen gesetzt werden. Der folgende Compare-Befehl testet die Register <code>gr10</code> und <code>gr11</code> auf Gleichheit. Das Predicate-Register <code>p1</code> wird mit Resultat, das Register <code>p2</code> mit dessen Negation geladen.

	cmp.eq p1,p2 = gr10,gr11 ; teste gr10 mit gr11 auf equal		cmp.eq p1,p2 = gr10,gr11 ; teste gr10 mit gr11 auf equal

Namibj: Ziel von Fetch auf die gewünschte Bedeutung geändert und Schreibweise angepasst.

2015-10-07T22:11:44Z

Ziel von Fetch auf die gewünschte Bedeutung geändert und Schreibweise angepasst.

← Nächstältere Version		Version vom 8. Oktober 2015, 00:11 Uhr
Zeile 15:		Zeile 15:
	* {{lang\|en\|predication}}: Unter {{lang\|en\|Predication}} (Aussage, Behauptung) versteht man die bedingte Ausführung von Befehlen ohne Verwendung von Sprungbefehlen.		* {{lang\|en\|predication}}: Unter {{lang\|en\|Predication}} (Aussage, Behauptung) versteht man die bedingte Ausführung von Befehlen ohne Verwendung von Sprungbefehlen.
	* {{lang\|en\|speculation}}: Damit im Befehlsablauf nicht auf Daten gewartet werden muss, können Daten zu einem frühen Zeitpunkt spekulativ geladen und bearbeitet werden.		* {{lang\|en\|speculation}}: Damit im Befehlsablauf nicht auf Daten gewartet werden muss, können Daten zu einem frühen Zeitpunkt spekulativ geladen und bearbeitet werden.
	* {{lang\|en\|Load/Store}}-Architektur: Speicherzugriffe kommen nur in Load- und Store-Befehlen vor (und natürlich beim [[~~Fetch~~]]).		* {{lang\|en\|Load/Store}}-Architektur: Speicherzugriffe kommen nur in Load- und Store-Befehlen vor (und natürlich beim [[Von-Neumann-Zyklus#FETCH\|FETCH]]).
	* Große Registersätze: Die Load/Store-Architektur benötigt viele Register, um die Anzahl der Speicherzugriffe möglichst klein zu halten.		* Große Registersätze: Die Load/Store-Architektur benötigt viele Register, um die Anzahl der Speicherzugriffe möglichst klein zu halten.
	* {{lang\|en\|register stack}} und {{lang\|en\|register engine}}: Die Register sind so angeordnet, dass innerhalb einer Prozedur die statischen Register und die von der Prozedur verwendeten Register sichtbar sind. Die Register werden beim Prozeduraufruf dynamisch umbenannt. Die {{lang\|en\|register engine}} sichert die im Moment nicht sichtbaren Register bei Bedarf im Speicher, so dass für ein Anwenderprogramm die Anzahl Register unbeschränkt ist.		* {{lang\|en\|register stack}} und {{lang\|en\|register engine}}: Die Register sind so angeordnet, dass innerhalb einer Prozedur die statischen Register und die von der Prozedur verwendeten Register sichtbar sind. Die Register werden beim Prozeduraufruf dynamisch umbenannt. Die {{lang\|en\|register engine}} sichert die im Moment nicht sichtbaren Register bei Bedarf im Speicher, so dass für ein Anwenderprogramm die Anzahl Register unbeschränkt ist.

DerSpezialist: Typographie, Formulierungen

2015-09-20T15:20:14Z

Typographie, Formulierungen

Änderungen zeigen

Summ am 28. Februar 2015 um 20:59 Uhr

2015-02-28T20:59:11Z

← Nächstältere Version		Version vom 28. Februar 2015, 22:59 Uhr
Zeile 109:		Zeile 109:
	{{Navigationsleiste Prozessorarchitektur}}		{{Navigationsleiste Prozessorarchitektur}}

	[[Kategorie:Prozessorarchitektur]]		[[Kategorie:Prozessorarchitektur nach Befehlssatz]]

← Nächstältere Version		Version vom 8. Oktober 2015, 00:11 Uhr
Zeile 15:		Zeile 15:
	* {{lang\|en\|predication}}: Unter {{lang\|en\|Predication}} (Aussage, Behauptung) versteht man die bedingte Ausführung von Befehlen ohne Verwendung von Sprungbefehlen.		* {{lang\|en\|predication}}: Unter {{lang\|en\|Predication}} (Aussage, Behauptung) versteht man die bedingte Ausführung von Befehlen ohne Verwendung von Sprungbefehlen.
	* {{lang\|en\|speculation}}: Damit im Befehlsablauf nicht auf Daten gewartet werden muss, können Daten zu einem frühen Zeitpunkt spekulativ geladen und bearbeitet werden.		* {{lang\|en\|speculation}}: Damit im Befehlsablauf nicht auf Daten gewartet werden muss, können Daten zu einem frühen Zeitpunkt spekulativ geladen und bearbeitet werden.
	* {{lang\|en\|Load/Store}}-Architektur: Speicherzugriffe kommen nur in Load- und Store-Befehlen vor (und natürlich beim [[~~Fetch~~]]).		* {{lang\|en\|Load/Store}}-Architektur: Speicherzugriffe kommen nur in Load- und Store-Befehlen vor (und natürlich beim [[Von-Neumann-Zyklus#FETCH\|FETCH]]).
	* Große Registersätze: Die Load/Store-Architektur benötigt viele Register, um die Anzahl der Speicherzugriffe möglichst klein zu halten.		* Große Registersätze: Die Load/Store-Architektur benötigt viele Register, um die Anzahl der Speicherzugriffe möglichst klein zu halten.
	* {{lang\|en\|register stack}} und {{lang\|en\|register engine}}: Die Register sind so angeordnet, dass innerhalb einer Prozedur die statischen Register und die von der Prozedur verwendeten Register sichtbar sind. Die Register werden beim Prozeduraufruf dynamisch umbenannt. Die {{lang\|en\|register engine}} sichert die im Moment nicht sichtbaren Register bei Bedarf im Speicher, so dass für ein Anwenderprogramm die Anzahl Register unbeschränkt ist.		* {{lang\|en\|register stack}} und {{lang\|en\|register engine}}: Die Register sind so angeordnet, dass innerhalb einer Prozedur die statischen Register und die von der Prozedur verwendeten Register sichtbar sind. Die Register werden beim Prozeduraufruf dynamisch umbenannt. Die {{lang\|en\|register engine}} sichert die im Moment nicht sichtbaren Register bei Bedarf im Speicher, so dass für ein Anwenderprogramm die Anzahl Register unbeschränkt ist.

← Nächstältere Version		Version vom 13. Juni 2019, 23:36 Uhr
Zeile 1:		Zeile 1:
	{{Belege fehlen\|2=Der gesamte Artikel}}		{{Belege fehlen\|2=Der gesamte Artikel}}

	Das '''Explicitly Parallel Instruction Computing''' ('''EPIC''') bezeichnet ein [[Programmierparadigma]] einer [[Befehlssatzarchitektur]] ({{EnS\|''Instruction Set Architecture''}}, kurz ''ISA'') und der Verarbeitungsstruktur einer Familie von [[Mikroprozessor]]en, z. B. [[Itanium]]. Bei der [[Programmierung]] von EPIC-CPUs wird die Parallelisierung der Befehle eines Instruktionsstromes explizit vorgenommen. Die ISA hat Eigenschaften, die die explizite [[Parallele Programmierung\|Parallelisierung]] unterstützen, während eine herkömmliche ISA von einer sequentiellen Abarbeitung der Befehle ausgeht. Ein Programm, das in einer Nicht-EPIC [[Maschinensprache]] vorliegt, kann auch parallelisiert werden, aber es ist bei der Ausführung eine komplexe [[Logikgatter\|Logik]] notwendig um parallel ausführbare Instruktionen zu identifizieren, da das Befehlsformat keine Aussagen über parallelisierbare Instruktionen macht. Eine EPIC-[[Hauptprozessor\|CPU]] arbeitet nach dem Prinzip der [[in-order execution\|in-order Execution]], im Gegensatz zur out-of-order execution der [[Superskalarität\|superskalaren]] CPUs.		Das '''Explicitly Parallel Instruction Computing''' ('''EPIC''') bezeichnet ein [[Programmierparadigma]] einer [[Befehlssatzarchitektur]] ({{EnS\|''Instruction Set Architecture''}}, kurz ''ISA'') und der Verarbeitungsstruktur einer Familie von [[Mikroprozessor]]en, z. B. [[Itanium]]. Bei der [[Programmierung]] von EPIC-CPUs wird die Parallelisierung der Befehle eines Instruktionsstromes explizit vorgenommen. Die ISA hat Eigenschaften, die die explizite [[Parallele Programmierung\|Parallelisierung]] unterstützen, während eine herkömmliche ISA von einer sequentiellen Abarbeitung der Befehle ausgeht. Ein Programm, das in einer Nicht-EPIC-[[Maschinensprache]] vorliegt, kann auch parallelisiert werden, aber es ist bei der Ausführung eine komplexe [[Logikgatter\|Logik]] notwendig, um parallel ausführbare Instruktionen zu identifizieren, da das Befehlsformat keine Aussagen über parallelisierbare Instruktionen macht. Eine EPIC-[[Hauptprozessor\|CPU]] arbeitet nach dem Prinzip der [[in-order execution\|in-order Execution]], im Gegensatz zur out-of-order execution der [[Superskalarität\|superskalaren]] CPUs.

	Die Motivation zur Entwicklung eines EPIC Prozessors ist die Reduktion der [[Logikgatter]] des Prozessors. Der nun frei gewordene Platz kann dazu benutzt werden, weitere funktionale Einheiten (z. B. Rechenwerke) in die CPU zu integrieren um:		Die Motivation zur Entwicklung eines EPIC-Prozessors ist die Reduktion der [[Logikgatter]] des Prozessors. Der nun frei gewordene Platz kann dazu benutzt werden, weitere funktionale Einheiten (z. B. Rechenwerke) in die CPU zu integrieren, um
	* die Anzahl der parallel ausführbaren Operationen zu erhöhen,		* die Anzahl der parallel ausführbaren Operationen zu erhöhen,
	* größere [[Cache]]s in den Prozessor zu integrieren,		* größere [[Cache]]s in den Prozessor zu integrieren,
	* den Einfluss des Flaschenhalses Hauptspeicher zu verringern oder		* den Einfluss des Flaschenhalses ''Hauptspeicher'' zu verringern oder
	* den Stromverbrauch, die Verlustleistung und damit Wärmeabgabe zu reduzieren.		* den Stromverbrauch, die Verlustleistung und damit die Wärmeabgabe zu reduzieren.

	Die {{lang\|en\|out-of-order execution}} ist teilweise auch aus dem Zwang zur Rückwärtskompatibilität zu älteren Prozessoren entstanden. Da das Befehlsformat eines älteren Prozessors weiterhin unterstützt werden musste, konnten Verbesserungen zur parallelen Ausführung nur unter der Haube geschehen. Prinzipiell ist es aber möglich, den [[Compiler]] mit dieser Aufgabe zu betrauen, und in den meisten Fällen ist ein Compiler für diese Aufgabe besser geeignet, da er mehr Zeit auf die Optimierung aufwenden kann und Zugriff auf mehr Informationen über den Programmfluss hat.		Die {{lang\|en\|out-of-order execution}} ist teilweise auch aus dem Zwang zur Rückwärtskompatibilität zu älteren Prozessoren entstanden. Da das Befehlsformat eines älteren Prozessors weiterhin unterstützt werden musste, konnten Verbesserungen zur parallelen Ausführung nur unter der Haube geschehen. Prinzipiell ist es aber möglich, den [[Compiler]] mit dieser Aufgabe zu betrauen, und in den meisten Fällen ist ein Compiler für diese Aufgabe besser geeignet, da er mehr Zeit auf die Optimierung aufwenden kann und Zugriff auf mehr Informationen über den Programmfluss hat.
Zeile 17:		Zeile 17:
	* {{lang\|en\|predication}}: Unter {{lang\|en\|Predication}} (Aussage, Behauptung) versteht man die bedingte Ausführung von Befehlen ohne Verwendung von Sprungbefehlen.		* {{lang\|en\|predication}}: Unter {{lang\|en\|Predication}} (Aussage, Behauptung) versteht man die bedingte Ausführung von Befehlen ohne Verwendung von Sprungbefehlen.
	* {{lang\|en\|speculation}}: Damit im Befehlsablauf nicht auf Daten gewartet werden muss, können Daten zu einem frühen Zeitpunkt spekulativ geladen und bearbeitet werden.		* {{lang\|en\|speculation}}: Damit im Befehlsablauf nicht auf Daten gewartet werden muss, können Daten zu einem frühen Zeitpunkt spekulativ geladen und bearbeitet werden.
	* {{lang\|en\|Load/Store}}-Architektur: Speicherzugriffe kommen nur in Load- und Store-Befehlen vor (und natürlich beim [[Von-Neumann-Zyklus#FETCH\|~~FETCH~~]]).		* {{lang\|en\|Load/Store}}-Architektur: Speicherzugriffe kommen nur bei Load- und Store-Befehlen vor (und natürlich beim [[Von-Neumann-Zyklus#FETCH\|Fetch-Zyklus]]).
	* Große Registersätze: Die Load/Store-Architektur benötigt viele Register, um die Anzahl der Speicherzugriffe möglichst klein zu halten.		* Große Registersätze: Die Load/Store-Architektur benötigt viele Register, um die Anzahl der Speicherzugriffe möglichst klein zu halten.
	* {{lang\|en\|register stack}} und {{lang\|en\|register engine}}: Die Register sind so angeordnet, dass innerhalb einer Prozedur die statischen Register und die von der Prozedur verwendeten Register sichtbar sind. Die Register werden beim Prozeduraufruf dynamisch umbenannt. Die {{lang\|en\|register engine}} sichert die im Moment nicht sichtbaren Register bei Bedarf im Speicher, so dass für ein Anwenderprogramm die Anzahl Register unbeschränkt ist.		* {{lang\|en\|register stack}} und {{lang\|en\|register engine}}: Die Register sind so angeordnet, dass innerhalb einer Prozedur die statischen Register und die von der Prozedur verwendeten Register sichtbar sind. Die Register werden beim Prozeduraufruf dynamisch umbenannt. Die {{lang\|en\|register engine}} sichert die im Moment nicht sichtbaren Register bei Bedarf im Speicher, so dass für ein Anwenderprogramm die Anzahl Register unbeschränkt ist.