Gibt es eine optimale Maschinensprache (Mikrocontroller, Mikroprozessor), die auf der einen Seite minimale Ressourcen (z. B. des FPGAs) benötigt und auf der anderen eine hohe Rechenleistung bietet? Kennt jemand eine Studie, die sich dieses Themas angenommen hat? Viele Grüße Herbert
Ich vermute mal, dass die jeweiligen Maschinensprachen normalerweise schon optimal an ihre Maschinen (CPU etc.) angepasst sind. Bin aber kein Informatiker
Herbert schrieb: > hohe Rechenleistung bietet kann dann eine Sprache überhaupt Rechenleistung liefern?
Herbert schrieb: > Gibt es eine optimale Maschinensprache Nein, natürlich nicht, je nach Programm wäre eine andere Sprache optimal. Auch je nach Hardware, interne CPU Chipgeschwindigkeit vs. RAM Zugriffsgeschwindigkeit auf den Programmspeicher ergeben sich unterschiedliche Codierungen. Ist die CPU schneller als das RAM, konnte eine Huffman-Codierung der OpCodes und ihrer Operanden nach Verwendungs-Häufigkeit sinnvoll sein, weil dann die Datenmenge die vom Programmspeicher in die CPU geschaufelt werden muss minimal wird, der Transputer hat das zumindest byteorientiert versucht war aber grottenlangsam. Ist die CPU langsamer als das RAM, kann es sinnvoll sein, die Microcodes nach aussen zu bringen, also ungefähr das was RISC macht, aber die CPU ist selten bis nie langsmaer als das RAM.
Herbert schrieb: > Gibt es eine optimale Maschinensprache (Mikrocontroller, > Mikroprozessor), die auf der einen Seite minimale Ressourcen (z. B. des > FPGAs) benötigt und auf der anderen eine hohe Rechenleistung bietet? > Kennt jemand eine Studie, die sich dieses Themas angenommen hat? > > Viele Grüße > > Herbert Was verstehst du unter Maschinensprache? CPU != FPGA Eine CPU hat sequentielle Aktionen, die sich z.B. mit Assembler sehr präzise auf der "untersten" Ebene beschreiben lassen. Wenn du dass richtig machst, wird es nicht mehr viel besser. Bei FPGA wird das Hardwarelayout beschrieben. Hier ist VHDL schon genau das richtige, viel besser wird es da auch nicht. Ok, du kannst die Gate-Tabelle selber von Hand schreiben, aber das ist nicht wirklich "besser". In beiden Fällen kommt es eher drauf an, dass dein Algorithmus stimmt. Die Sprache in der es geschrieben wird ist dann eher eine Frage von div. anderen Paramtern.
Herbert schrieb: > Gibt es eine optimale Maschinensprache (Mikrocontroller, > Mikroprozessor), die auf der einen Seite minimale Ressourcen (z. B. des > FPGAs) benötigt und auf der anderen eine hohe Rechenleistung bietet? > Kennt jemand eine Studie, die sich dieses Themas angenommen hat? Das Thema ist gemeinhin als RISC und CISC bekannt. Und irgendwo dort, wo sich der ARM-Kern tummelt liegt ein lokales Maximum.
Herbert schrieb: > Gibt es eine optimale Maschinensprache (Mikrocontroller, > Mikroprozessor), die auf der einen Seite minimale Ressourcen (z. B. des > FPGAs) benötigt und auf der anderen eine hohe Rechenleistung bietet? > Kennt jemand eine Studie, die sich dieses Themas angenommen hat? Studie da gibt es ganze Lehrbücher zu! Meine Empfehlung: https://www.amazon.de/Rechnerarchitektur-Implementierung-Bewertung-Lehrbuch-Informatik/dp/3528051736 besser die amerikanische aktuelle Originalausgabe. https://www.amazon.com/Computer-Architecture-Fifth-Quantitative-Approach/dp/012383872X Ist zwar nicht FPGA-spezifisch bezieht aber dafür Software/Betriebssysteme ein. Was nützt ein Prozessor der auf synthetische Benchmarks optimiert ist?! Anderes Stichwort zum Thema Prozessorentwurf ist -DLX https://en.wikipedia.org/wiki/DLX -Acorn Risc Machine - in dessen Entwicklung akademischer Forschungen zum optimalen Befehlssatz aufgenommen wirden und beispielsweise zur Aufnahme der Conditional Execution in den Befehlssatz führte -SPARC - auch ein auf akadeimsiche Arbeiten hin entwickelte Architecture, insbesonders der Register windowing Ansatz ist interessant -VLIW falls du dich auch für DSP-Architekturen interessierst
Eine CPU ist generel purpose computing. Es ist eine allgemeine Recheneinheit für alle möglichen Probleme. Eine CPU macht ja nichts anderes als Daten von A nach B zu schaufeln und noch ein paar Grundrechnungsarten. Wer optimale Lösungen für ein Problem benötigt nimmt ein FPGA und programmiert sich einen Chip der nur diese Problem löst, dafür aber optimal. Eine optimale Maschinensprache für eine CPU gibt es wohl auch nicht. Für MCUs ist oft wichtig das die generierte Code Größe klein ist, für PCs das sie schnell ist. Studien haben gezeigt das für über 90% des Programmcodes nur wenige Befehle gebraucht werden. Daraus ist die RISC Architektur entstanden. Bei CISC brauchen komplexe Befehle viele Taktzyklen. Bei RISC braucht jeder Befehl nur einen Taktzyklus. Zudem kann die CPU wesentlich einfacher gebaut werden und verbraucht wesentlich weniger Leistung. Komplexere Aufgaben müssen allerdings mittels Software gelöst werden. Der ARM Architektur wird nachgesagt das sie eine sehr schöne Architektur ist. 8086 war von Anfang an eine grausame Architektur und nur durch AMD64 wurde es besser aber der 8086 Schrott befindet sich noch in jeder PC CPU. Im Vergleich zu 8086 war die Motorola 68000 Architektur schon wesentlich schöner. Der Befehlssatz lehnte sich an die VAX an.
Herbert schrieb: > Gibt es eine optimale Maschinensprache Eine optimale Lösung existiert generell nur für ein spezifisches Problem. Etwas, das für jeden beliebigen Anwendungsfall optimal ist, existiert nicht.
:
Bearbeitet durch User
bitwurschtler schrieb: > -Acorn Risc Machine - in dessen Entwicklung akademischer Forschungen zum > optimalen Befehlssatz aufgenommen wirden und beispielsweise zur Aufnahme > der Conditional Execution in den Befehlssatz führte Und ebenso zur Abschaffung der Conditional Execution mit 64bit ARM. ;-) > -SPARC - auch ein auf akadeimsiche Arbeiten hin entwickelte > Architecture, insbesonders der Register windowing Ansatz ist interessant Dieses Windowing hat ebenso Vor- und Nachteile. Ein Nachteil wäre beispielsweise, dass von der mit Abstand teuersten verfügbaren Speicher-Ressource innerhalb einer Funktion immer nur ein kleiner Teil verwendet wird. Deshalb: Im Laufe der Zeit kommt man aufgrund besserer statistischer Erfassung der Laufzeitverhältnisse und weiter entwickelter Hard- und Software zu unterschiedlichen Ergebnissen kommen. Das muss auch kein asymptotischer Prozess sein. Die Entwicklung integrierter grösserer Caches hat die Grundlagen bestehender und an die bisherige Situation gut angepasster Architekturen zertrümmert. Die Entwicklung immer ausgefuchsterer Sprungvorhersagen blieb nicht ohne Einfluss auf Predication / Conditional Execution. Kommt ein neues Konzept hinzu können bestehende Strategien schnell veralten.
Fürn Hugo schrieb: > Im Vergleich zu 8086 war die Motorola 68000 Architektur schon wesentlich > schöner. Der Befehlssatz lehnte sich an die VAX an. Fast. Immerhin stimmt DEC. ;-) Den dominanten Einfluss hatte die PDP-11, nicht die VAX.
Herbert schrieb: > Gibt es eine optimale Maschinensprache Was du meinst nennt sich "Instruction Set Architecture" (ISA). Wird gebildet aus Befehlssatz und den darin direkt angesprochenen Ressource wie den Registern. Im Gegensatz dazu gibt es die "Implementation Architecture", die den inneren Aufbau beschreibt. Bei Architekturen grösserer Lebensdauer fällt auf, das diese Teile nur anfangs gut aufeinander passen, später aber auseinander laufen. So wiederspiegelt die Implementierung der x86 ISA in heutigen Prozessoren diese alte Architektur in keiner Weise mehr wieder. Im Grunde spielt ein Core i7 nach aussen hin Theater. Auch RISC ist davor nicht gefeit: In der PowerPC ISA steckt nutzloserweise noch heute IBMs erste Mehrchip-Implementierung im Design, und Delay-Slots wie in MIPS sind mittlerweile eher Problem als Vorzug.
Fürn Hugo schrieb: > Der Befehlssatz lehnte sich an die VAX an. PS: Wobei es das natürlich auch gab. National Semiconductors NS32000 war von der VAX geprägt, noch krasser jedoch eine Totgeburt von NEC.
Moving Target. Damals (TM) war RISC der Hype, weil einfach in HW umzusetzen. Ganze ALUs auf dem Platz des Befehlsdecoders einer x86 oder 68k Maschine. Jetzt leben wir in einer Zeit in der die ALU bzw. ein "Kern" einer CPU im bereich << 10% Chipfläche ist und die ISA eigentlich nur noch eine untergeordnete Rolle spielt. Intern ist eh alles was Performance hat nach µOPs oder ähnlichem aufgebaut. Dann kann die ach so schlimme x86 ISA auch wieder punkten: Durch den nicht existenten Zwang zu 1 Takt/Befehl und eben nicht konstanter Länge der Opcodes wirkt das im Prinzip wie eine Kompression der Opcodes. Weniger Cache wird benötigt etc.
A. K. schrieb: > Die Entwicklung > integrierter grösserer Caches hat die Grundlagen bestehender und an die > bisherige Situation gut angepasster Architekturen zertrümmert. Für FPGA's gilt das nicht, zumindest nicht in dieser Schärfe. FPGA's haben immer noch vergleichsweise wenig Embedded RAM-Blöcke die man für Caches verbraten kann. Ebenfalls trägt die granular aufgebaute Logikgatter (4er LUT) der FPGA's mit bei, das man die Architektur von in FullCustom hingezauberten CPU's nicht mit den gleichen Vorteilen auf FPGA- (Soft)-Cores übertragen kann. Sonst muss man u.U. die Maximalfrequenz unerwartet runtersetzen weil diese Implementierung einen Logic-level mehr erfordert. Da macht es sinn das man alle Architekturtricks von CISC/RISC/MIMD nochmal auf FPGA hin optimiert durchdenkt.
Herbert schrieb: > Gibt es eine optimale Maschinensprache (Mikrocontroller, > Mikroprozessor), die auf der einen Seite minimale Ressourcen (z. B. des > FPGAs) benötigt und auf der anderen eine hohe Rechenleistung bietet? > Kennt jemand eine Studie, die sich dieses Themas angenommen hat? Wenn man zu 'minmale FPGA Resourcen' und 'hohe Rechenleistung' auch noch die Anforderungen: frei verwendbar, open-source C/C++ Compiler, und Erweiterbarkeit des Befehlssatzes hinzufügt ist die RISC-V Architektur ziemlich optimal. Skalierbar von kleinen 32bit Controllern bis zu Multicore 64- oder 128bit CPUs für Computer. Da an Universitäten entstanden, gibt es natürlich zahlreiche Studien und Abhandlungen dazu zum Lesen. Andi
bitwurschtler schrieb: > -Acorn Risc Machine - in dessen Entwicklung akademischer Forschungen zum > optimalen Befehlssatz aufgenommen wirden und beispielsweise zur Aufnahme > der Conditional Execution in den Befehlssatz führte IMHO ist das bei ARM64 rausgeflogen.
Karl schrieb: > Dann kann die ach so > schlimme x86 ISA auch wieder punkten: Durch den nicht existenten Zwang > zu 1 Takt/Befehl und eben nicht konstanter Länge der Opcodes wirkt das > im Prinzip wie eine Kompression der Opcodes. Weniger Cache wird benötigt > etc. mov rx,ry kann auf OOO MAschinen 0 Takte brauchen, und ARM-Thumb komprimiert auch.
Flieger schrieb: > bitwurschtler schrieb: > >> -Acorn Risc Machine - in dessen Entwicklung akademischer Forschungen zum >> optimalen Befehlssatz aufgenommen wirden und beispielsweise zur Aufnahme >> der Conditional Execution in den Befehlssatz führte > > IMHO ist das bei ARM64 rausgeflogen. Was nicht heisst das die Entscheidung vor 30 Jahren den Acorn Processor mit bedingter Befehlsausführung auszustatten falsch war. Es haben sich halt die Voraussetzungen geändert. Der Rausschmiss bei ARM64 wurde u.a. durch die mäßige Nutzung dieses Features durch die heutige Software begründet, aber nicht damit das es eine Architekturschwäche wäre.
Mark B. schrieb: > Flieger schrieb: >> mov rx,ry kann auf OOO MAschinen 0 Takte brauchen > > Hm, wie das? Je aktuellen OOO Cores gibt es keine festen Registerplätze mehr. Vielmehr wird bei jedem Befehl (genauer: jedem Mikrobefehl) ein neues Zielregister aus dem Pool gefischt und nach Abschuss wird dieses dann als aktuelles "rx" deklariert. Da bei eine MOV keine Veränderung auftritt kann man aber auch gleich das Register für "ry" dafür verwenden und sich die Kopie sparen.
Mark B. schrieb: > Flieger schrieb: >> mov rx,ry kann auf OOO MAschinen 0 Takte brauchen > > Hm, wie das? Register renaming? https://en.wikipedia.org/wiki/Register_renaming https://en.wikipedia.org/wiki/Out-of-order_execution
Ordner schrieb: > Was nicht heisst das die Entscheidung vor 30 Jahren den Acorn Processor > mit bedingter Befehlsausführung auszustatten falsch war. Es haben sich > halt die Voraussetzungen geändert. Bedingte Ausführung erspart bedingte Sprünge. Anfang der 80er war dynamische Sprungvorhersage nicht existent. Heute ist sie sehr weit entwickelt. Was dann noch an Unvorhersagbarem übrig bleibt lässt sich von bedingten Auswahlbefehlen abdecken, die z.B. {dst = cond ? src1 : src2;} implementieren, aber auch komplexere Formen wie {dst = cond ? src1 : src2+1;}
:
Bearbeitet durch User
Moin, > > Was nicht heisst das die Entscheidung vor 30 Jahren den Acorn Processor > mit bedingter Befehlsausführung auszustatten falsch war. Es haben sich > halt die Voraussetzungen geändert. > Der Rausschmiss bei ARM64 wurde u.a. durch die mäßige Nutzung dieses > Features durch die heutige Software begründet, aber nicht damit das es > eine Architekturschwäche wäre. Das Feature wird in einigen DSP-Architekturen immer noch sehr gern genutzt. Bei MIPS gabs was ähnliches mit dem "branch if likely"-Instruktionen. Ansonsten kann ich, was Kompaktheit von Programmen/Opcodes angeht, nur meine kleine interne Rangliste (Sieger zuerst, komplett empirisch erfasst) bieten: (1) MSP430 (2) ZPU (knapp dahinter) (3) ARM v5 thumb (4) MIPS16 (5) AVR8 (6) MIPS32 (7) i86-64 Basis ist eine für die versch. Arch. gcc-compilierte bare metal Library ohne float-Gerechne (dann sähe das alles wieder anders aus).
A. K. schrieb: > Ordner schrieb: >> Was nicht heisst das die Entscheidung vor 30 Jahren den Acorn Processor >> mit bedingter Befehlsausführung auszustatten falsch war. Es haben sich >> halt die Voraussetzungen geändert. > > Bedingte Ausführung erspart bedingte Sprünge. Anfang der 80er war > dynamische Sprungvorhersage nicht existent. Nö, die gab es schon früher, wurde aber bei den multicycle Architekturen nicht unbedingt benötigt. Erst mit immer tieferen Befehls-Pipelines und der damit verbundenen wartezyklen bei stall wurde die Sprungvermeidung relevant. Von einer compilerunterstützung hätten alte (Binär-)Programme nicht profitiert. Also musste man die Sprungvorhersage in den Prozessor "gießen" Die Hardware wurde an die (supotimale) Software angepasst. Bei Acorn dagegen gab es keine alten Programme, da startete Hard- und Software gleichzeitig bei Null und es hingen keine alten Kompatibilitätszöpfe im Getriebe.
Martin S. schrieb: > Ansonsten kann ich, was Kompaktheit von Programmen/Opcodes angeht, nur > meine kleine interne Rangliste (Sieger zuerst, komplett empirisch > erfasst) bieten: > > (1) MSP430 > (2) ZPU (knapp dahinter) > (3) ARM v5 thumb > (4) MIPS16 > (5) AVR8 > (6) MIPS32 > (7) i86-64 und MC68000 kommt auf Platz 8 ??
Ordner schrieb: >> Bedingte Ausführung erspart bedingte Sprünge. Anfang der 80er war >> dynamische Sprungvorhersage nicht existent. > > Nö, die gab es schon früher, Möglicherweise in den grösseren Rechnern, aber in Mikroprozessoren ist mir aus der Entstehungszeit von ARM keine dynamische Vorhersage bekannt. > Von einer compilerunterstützung hätten alte (Binär-)Programme nicht > profitiert. Also musste man die Sprungvorhersage in den Prozessor > "gießen" Die Hardware wurde an die (supotimale) Software angepasst. Heute findet man aus mehreren Gründen meist Kompromisse, fundamentalistische Ansätze weniger. Der RISC Ansatz, was nur irgend geht in den Compiler zu verlagern, wurde grad in dieser Hinsicht nicht bis ins Extrem getrieben. Am weitesten geht (ging?) wohl IA64 mit der nur dort voll entwickelten predication. Einer der Gründe: Den Core mit etwas zusätzlicher Hardware zu bewerfen, kostet mittlerweile wenig. Den Designern gehen ohnehin allmählich die neuen Ideen aus, womit sie die einzelnen Cores signifikant schneller kriegen können. Denn höhere Taktfrequenz scheidet praktisch aus.
:
Bearbeitet durch User
A. K. schrieb: > Den Designern gehen ohnehin allmählich die > neuen Ideen aus, womit sie die einzelnen Cores signifikant schneller > kriegen können. Denn höhere Taktfrequenz scheidet praktisch aus. Hm angeblich soll aber höhere Taktfrequenz ein Grund gewesen sein bedingte Ausführung rauszuschmeissen. Die Verdrahtung von Flags mit den condition bits des instructions word bildete wohl den (Taktbestimmenden) kritischen Pfad. Ob diese Takterhöhung die Wartezyklen kompensiert ist unbekannt. Der ARM64 scheint mir aber eh mehr in Richtung KlickikackiMultiMediHandy entwickelt und den Focus auf Effizienz hat man verloren. Und im Embedded ist mir ein effizenter Prozessor lieber als schnelle Heizplatte.. Dafür sollten die Designer mal ihre Ideen verwirklichen dürfen.
Ordner schrieb: > Hm angeblich soll aber höhere Taktfrequenz ein Grund gewesen sein > bedingte Ausführung rauszuschmeissen. Mir ging es eher um die thermische Situation, als um Signalpfade.
Ordner schrieb: > Der ARM64 scheint mir aber eh mehr in Richtung KlickikackiMultiMediHandy > entwickelt Natürlich. Das ist doch der bestimmende Markt. Embedded dürfte ARMv8 vorerst eher ein Nebeneffekt der Nutzung von Cores sein, die für Mobilanwendungen gebaut wurden. > und den Focus auf Effizienz hat man verloren. Keineswegs. Immerhin geht es beim Klickibunti-Markt genau darum. Weshalb die ARM Implementierungen schon eine Weile auf 2 getrennten Gleisen verlaufen, einerseits die effizienten A7/A53, andererseits die performanteren aber weniger effizienten A15/A53/A57/A72.
Ordner schrieb: > Hm angeblich soll aber höhere Taktfrequenz ein Grund gewesen sein > bedingte Ausführung rauszuschmeissen. Das hiesse aber doch, dass bestehende ARMv8 Implementierungen entweder nichts davon haben, oder im 64-Bit Betrieb schneller takten können als im 32-Bit Betrieb. Denn noch gibts wohl keinen ARMv8, der nicht auch ARMv7 enthielte.
A. K. schrieb: > Ordner schrieb: >> Hm angeblich soll aber höhere Taktfrequenz ein Grund gewesen sein >> bedingte Ausführung rauszuschmeissen. > > Mir ging es eher um die thermische Situation, als um Signalpfade. Ah,OK. Für mich als FPGA-Entwickler bestimmt der längste Pfad den Takt und nicht der Hitzetod. Notfalls kriegt der FPGA halt einen Kühler spendiert.
A. K. schrieb: > performanteren aber weniger effizienten A15/A53/A57/A72. performanteren aber weniger effizienten A15/A57/A72/A73.
A. K. schrieb: >> und den Focus auf Effizienz hat man verloren. > > Keineswegs. Immerhin geht es beim Klickibunti-Markt genau darum. Weshalb > die ARM Implementierungen schon eine Weile auf 2 getrennten Gleisen > verlaufen, einerseits die effizienten A7/A53, andererseits die > performanteren aber weniger effizienten A15/A53/A57/A72. Für mich ist KlickiBunti per se das Gegenteil von Effizienz, wer ein effizintes Telefon bauen will der macht es nicht Klickibunti. Und ich möchte auch nicht weiter um den Wandel des Effizienzbegriffs bei ARM diskutieren sondern lieber um optimaler Prozessor/Hardware für FPGA-Architekturen. Jajajaaj ich weiss - ich hab selbst damit angefangen aber nun hab ich genug.
Ordner schrieb: > Die Verdrahtung von Flags mit den condition bits des instructions word > bildete wohl den (Taktbestimmenden) kritischen Pfad. Das dürfte auch der Grund sein, dass RISC-V keine Flags hat.
Ordner schrieb: > Für mich ist KlickiBunti per se das Gegenteil von Effizienz, wer ein > effizintes Telefon bauen will der macht es nicht Klickibunti. Sind wir noch bei Prozessoren, oder schon bei Benutzeroberflächen?
S. R. schrieb: > Das dürfte auch der Grund sein, dass RISC-V keine Flags hat. Der liegt woanders: Flags in einem Statusregister und ihre Verwendung sind im Befehlsablauf eng gekoppelt, die Flags sind singuläre Ressourcen, die einer Codeoptimierung im Weg stehen können. Du kannst eine in einem Flag endende Bedingung beispielsweise nicht aus der Schleife hinaus befördern, weil das Flag meist nicht lange genug gültig bleibt. Steht die Bedingung hingegen in einem normalen Register (MIPS, Alpha) oder in einem von vielen Bedingungsregistern (PowerPC, IA64), dann geht das. Die Vermeidung solcher singulärer Ressourcen gehörte schon früh zu den RISC Strategien. Nicht immer früh genug. Das OOO und Pipelining etwas im Weg stehende MQ Register verlor IBMs POWER erst mit der Entwicklung zur PowerPC Architektur.
:
Bearbeitet durch User
Ordner schrieb: ... > > und MC68000 kommt auf Platz 8 ?? Das glaub' ich nicht. Von dem (richtig schön orthogonalen) Befehlssatz benutzen gängige Compiler kaum die Hälfte. Und auch gute Assembler-Programmierer nicht alles. Aus dieser Erkenntnis heraus hat Motorola die ColdFire Chips erfunden.
Markus F. schrieb: > ... >> >> und MC68000 kommt auf Platz 8 ?? > > Das glaub' ich nicht. Von dem (richtig schön orthogonalen) Befehlssatz > benutzen gängige Compiler kaum die Hälfte. Und auch gute > Assembler-Programmierer nicht alles. > > Aus dieser Erkenntnis heraus hat Motorola die ColdFire Chips erfunden. 68k habe ich nicht auf der Liste...würde ihn aber als eher kompakt einschätzen, von den guten alten Atari-Zeiten her.
"Maschinensprache" ist das, was die Hardware (der Prozessor) ausführt. Also irgendein Bitmuster, welches im "Befehlsregister" ankommt und interpretiert / verarbeitet wird. Da ist nichts mit optimal, weil die Hardware (der Prozessor) genau das verstehen muss. Optimieren kann man vorher - im Assembler (der Mnemonics in Maschinensprache übersetzt) oder noch weiter zuvor mit der Wahl des Compilers, der irgendeine Programmiersprache compiliert. Und natürlich mit der Wahl des Prozessors bzw. der Wahl dessen Eigenschaften.
A. K. schrieb: > Vielmehr wird bei jedem Befehl (genauer: jedem Mikrobefehl) ein neues > Zielregister aus dem Pool gefischt und nach Abschuss wird dieses dann > als aktuelles "rx" deklariert. Da bei eine MOV keine Veränderung > auftritt kann man aber auch gleich das Register für "ry" dafür verwenden > und sich die Kopie sparen. Spannend - sozusagen ein intuitiver Prozessor(-kern), der weiß das ich ry meine wenn ich rx anspreche. Natürlich hat ry auch gleich den passenden Inhalt von rx (oder ra, ... ,rz ?). Kannst Du diese Technik bitte etwas näher erläutern?
Dieter F. schrieb: > "Maschinensprache" ist das, was die Hardware (der Prozessor) ausführt. > Also irgendein Bitmuster, welches im "Befehlsregister" ankommt und > interpretiert / verarbeitet wird. Da ist nichts mit optimal, weil die > Hardware (der Prozessor) genau das verstehen muss. > > Optimieren kann man vorher - im Assembler (der Mnemonics in > Maschinensprache übersetzt) oder noch weiter zuvor mit der Wahl des > Compilers, der irgendeine Programmiersprache compiliert. Und natürlich > mit der Wahl des Prozessors bzw. der Wahl dessen Eigenschaften. Sogar auf der Maschinenbene, mit den binären Befehlen im Speicher, wird heute optimiert. In Hardware. Voneinander unabhängige Operationen werden gleichzeitig ausgeführt, u.U. auch wenn sie 20 Befehle weit voneinander entfernt werden. Loads werden ausgeführt sobald die Adresse bekannt ist, egal ob man weiss, ob der Inhalt benötigt wird oder nicht. Und nicht unbedingt in der Reihenfolge, in der Speicheroperationen im Programm stehen. Das kann schon mal ins Auge gehen, wenn ein Store dazwischen funkt, weshalb dann eben an passender Stelle neu aufgesetzt wird. Loads werden teilweise ausgeführt, bevor überhaupt ein Befehl gesehen wurde, der sie benötigen könnte, weil das bisherige Verhalten das nahelegt. ... nur ein paar Beispiele.
A. K. schrieb: > Loads werden teilweise ausgeführt, bevor überhaupt ein Befehl gesehen > wurde, der sie benötigen könnte, weil das bisherige Verhalten das > nahelegt Hast Du dafür eine (verlässliche) Quelle? Die "Schaltung" arbeitet also auch "intuitiv"? Das ist "hart verdrahtet" - daher habe ich ein Verständnisproblem mit intuitiven Aktionen.
Dieter F. schrieb: > Hast Du dafür eine (verlässliche) Quelle? Die "Schaltung" arbeitet also > auch "intuitiv"? Das ist "hart verdrahtet" - daher habe ich ein > Verständnisproblem mit intuitiven Aktionen. Das hat nichts mit Intuition zu tun, eher mit Vorsehung ;-) https://de.wikipedia.org/wiki/Explicitly_Parallel_Instruction_Computing#Speculation
Dieter F. schrieb: > Spannend - sozusagen ein intuitiver Prozessor(-kern), der weiß das ich > ry meine wenn ich rx anspreche. Natürlich hat ry auch gleich den > passenden Inhalt von rx (oder ra, ... ,rz ?). Im Grunde geht es darum, dass es, wie schon angerissen, kein definertes AX/EAX/RAX register mehr gibt, um mal bei x86 zu bleiben. Sondern eine dreistellige Anzahl Register (der erwähnte Pool) und zwei Tabellen, wo sich darin RAX/RBX/RCX/... grad befindet, oder irgendwann befinden wird. Eine Tabelle beschreibt den spekulativen Stand dieser Abbildung, der im erweiterten Rahmen der Dekodierung noch sequentiell ausgewertet wird (aber mehrere Ops pro Takt). Besagt die Tabelle, dass der Wert schon drin steht, und das gilt für alle Inputs, dann gilt "Feuer frei". Andernfalls muss gewartet werden, bis eine der Ausführungseinheiten signalisiert, dass das fehlende Register 87 in Kürze beliefert wird. Und eine zweite Tabelle beschreibt den abschliessenden Stand nach endgültigem ebenfalls wieder sequentiell erfolgenden sequentiellen Abschluss eines Befehls. Auf letzteren Stand kann man jederzeit wieder zurückfallen. Zwischendurch kann es in der Ausführungsreihenfolge recht durcheinander gehen. Basierend auf dieser Methode ist ein MOV rx,ry nur eine Modifikation der besagten Tabellen. Eine Ausführungseinheit, die Inhalt des Registers kopiert, ist unöntig. > > Kannst Du diese Technik bitte etwas näher erläutern? Die Grundlagen von register renaming und out of order excution hier zu beschreiben wäre definitiv zu viel. Oben sind 2 Links, aber Google hilft auch. Die oben angesprochene MOV Optimierung steht vielleicht nicht überall drin, denn die ist relativ neu, ergibt sich daraus aber als nahe liegende Möglichkeit.
Dieter F. schrieb: > daher habe ich ein > Verständnisproblem mit intuitiven Aktionen. Das ist nicht intuitiv, sondern spekulativ. Was out of order loads angeht, in stark vereinfachter Darstellung: Man führt die Loads so aus, wie die Adressen dazu fertig werden und grad ein Slot in einer Load-Unit frei wird. Wild durcheinander. Und protokolliert in einem assoziativen Speicher mit, welche Adressen schon durch waren. Stösst dann ein älterer Store auf eine solche Adresse, und es wird dadurch ein Konflikt in der Reihenfolge signalisiert, dann wirft man eben den gesamten spekulativen Stand weg und setzt im stabilen Stand (obige zweite Tabelle) frisch auf. Solche Spekulation (wie auch bei Sprüngen und internen Operationen) beschleunigt Prozessoren erheblich, ist aber recht aufwändig und führt zu sehr viel sinnloser interner Arbeit. Und die kostet Strom, mehr Leistung pro ausgeführtem Befehl, als im Prinzip nötig wäre. Das ist ein wesentlicher Grund, weshalb ARM zwei getrennte Core-Linien fährt. Den klassisch sequentiell arbeitenden und Strom sparenden Cortex A53 einerseits, und OOO Cores wie Cortex A73 andererseits. In besseren Handys sind ggf. beide drin. Die A72er sind normalerweise tot, werden aber aktiviert wenn Leistung gefragt ist.
:
Bearbeitet durch User
Ab Haswell geht das noch ein Stück weiter. Um zeitraubende Synchronisation zwischen vielen Threads zu beschleunigen erspart man sich zunächst die zeitraubende Synchronisation völlig und tut einfach so, als ob kein Konflikt bestünde. Stellt der Core am Ende des solchen Abschnitts fest, dass es doch einen Konflikt gab, dann schmeisst er alles weg, was zwischendrin passierte, und setzt nochmal am Anfang auf. Hier muss aber der Programmierer etwas mitarbeiten, indem er diese Anfang/Ende-Klammer definiert und aufpasst, was genau er zwischendrin macht.
A. K. schrieb: > Basierend auf dieser Methode ist ein MOV rx,ry nur eine Modifikation der > besagten Tabellen. Eine Ausführungseinheit, die Inhalt des Registers > kopiert, ist unöntig. wie das? also der klassische "mov" Befehl einer jeder CPU die ich kenne ist ja eigentlich ein "Copy" Befehl oder nicht? Bei welcher CPU gibt es enen "echten" move? z.B. 8051 http://www.self8051.de/MOV_A,Rr,13495.html https://de.wikipedia.org/wiki/Motorola_68000 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihcdbca.html
bko schrieb: > A. K. schrieb: >> Basierend auf dieser Methode ist ein MOV rx,ry nur eine Modifikation der >> besagten Tabellen. Eine Ausführungseinheit, die Inhalt des Registers >> kopiert, ist unöntig. > > wie das? also der klassische "mov" Befehl einer jeder CPU die ich kenne > ist ja eigentlich ein "Copy" Befehl oder nicht? > Bei welcher CPU gibt es enen "echten" move? Falsche Frage. Es geht hier nicht um move vs copy. Dass ein MOV Befehl eigentlich falsch heisst, daran muss man sich gewöhnen. Es geht einfach nur darum, dass bei besagtem 0-cycle MOV Rx,Ry eben vorher per register_map[Rx] == 65 register_map[Ry] == 87 signalisiert ist, dass sich der bisherige Inhalt von Rx in Register 65 befindet, und nacher in Register 87 register_map[Rx] == 87 register_map[Ry] == 87 Es wird also schon etwas kopiert, aber eben nicht der Inhalt des Registers, sondern die Information darüber, wo man den findet.
:
Bearbeitet durch User
Sven D. schrieb: > Das hat nichts mit Intuition zu tun, eher mit Vorsehung ;- Prima - und für welche MC's gilt das? Wir sind hier nicht im Pentium xx / Irgendwas yy - Univrsum unterwegs sondern auf MC-Basis (nomen est omen). Es wäre schön, wenn Du das belegen könntest ...
A. K. schrieb: > signalisiert ist, dass sich der bisherige Inhalt von Rx in Register 65 > befindet, und nacher in Register 87 Und woher kommt diese Information (Takt-unabhängig)?
A. K. schrieb: > Es geht einfach > nur darum, dass bei besagtem 0-cycle MOV Rx,Ry eben vorher per > register_map[Rx] == 65 > register_map[Ry] == 87 > signalisiert ist, dass sich der bisherige Inhalt von Rx in Register 65 > befindet, und nacher in Register 87 > register_map[Rx] == 87 > register_map[Ry] == 87 Und woher weis der (was auch immer) das?
Dieter F. schrieb: > Prima - und für welche MC's gilt das? Wir sind hier nicht im Pentium xx > / Irgendwas yy - Univrsum unterwegs sondern auf MC-Basis (nomen est > omen). Eigentlich sind wir im Bereich FPGA/VHDL unterwegs. Zudem erwähnt der Startbeitrag ausdrücklich Mikroprozessoren, und da das Zeitalter von Mehrchip-Lösungen lange vorbei ist, ist vom AVR bis rauf zum Xeon alles erlaubt. ;-)
Dieter F. schrieb: > Und woher weis der (was auch immer) das? Zettel und Bleistift, symbolisch gesprochen. Also indem er die besagten Tabellen pflegt.
:
Bearbeitet durch User
Dieter F. schrieb: > Sven D. schrieb: >> Das hat nichts mit Intuition zu tun, eher mit Vorsehung ;- > > Prima - und für welche MC's gilt das? Wir sind hier nicht im Pentium xx > / Irgendwas yy - Univrsum unterwegs sondern auf MC-Basis (nomen est > omen). > > Es wäre schön, wenn Du das belegen könntest ... Naja STM32 haben zumindest teilweise einen "ART Accelerator"... das ist schonmal sowas in die richtung... aus dem STM32F205 datasheet: ... To release the processor full 150 DMIPS performance at this frequency, the accelerator implements an instruction prefetch queue and branch cache which increases program execution speed from the 128-bit Flash memory. ... 73
Dieter F. schrieb: > Prima - und für welche MC's gilt das? Wir sind hier nicht im Pentium xx > / Irgendwas yy - Univrsum unterwegs sondern auf MC-Basis (nomen est > omen). OOO ist in den Mikrocontrollern noch nicht drin, superskaler gibts mit dem Cortex M7 aber schon. Das wäre dann grob vergleichbar zum ursprünglichen Pentium. Wenn man aber sowas wie RasPi mit ins Forenspektrum einrechnet, das wird das Spektrum breiter, auch wenn in den derzeitigen SoCs dieser System auch noch kein OOO Core steckt - dafür aber immerhin schon A53er. Aber das ist wirklich nur eine Frage der Zeit.
Dieter F. schrieb: > Sven D. schrieb: >> Das hat nichts mit Intuition zu tun, eher mit Vorsehung ;- > > Prima - und für welche MC's gilt das? Wir sind hier nicht im Pentium xx > / Irgendwas yy - Univrsum unterwegs sondern auf MC-Basis (nomen est > omen). > > Es wäre schön, wenn Du das belegen könntest ... Was? Es wäre schön wenn Du den Zwinkersmiley erkennen könntest und wenn Du den verlinkten Wikipedia Artikel aufmerksam lesen könntest. Lies den Eingangspost nochmal, der TO hat nicht explizit nach Mikrocontrollern gefragt. Falls Dich das Thema wirklich interessiert Beginn hier https://de.wikipedia.org/wiki/Out-of-order_execution zu lesen, folge den Links im Artikel und dann wiederum den Links in den verlinkten Artikeln uswusf. Dann hast Du genug zu tun und lernst viel dazu. Der Wikipedialink in meinem Beitrag Beitrag "Re: Optimale Maschinensprache" dient dazu Dir zu zeigen, das A.K. das unten zitierte nicht erfunden hat. Dieter F. schrieb: > A. K. schrieb: >> Loads werden teilweise ausgeführt, bevor überhaupt ein Befehl gesehen >> wurde, der sie benötigen könnte, weil das bisherige Verhalten das >> nahelegt > > Hast Du dafür eine (verlässliche) Quelle? Die "Schaltung" arbeitet also > auch "intuitiv"? Das ist "hart verdrahtet" - daher habe ich ein > Verständnisproblem mit intuitiven Aktionen.
Dieter F. schrieb: > Hast Du dafür eine (verlässliche) Quelle? Die "Schaltung" arbeitet also > auch "intuitiv"? Das ist "hart verdrahtet" - daher habe ich ein > Verständnisproblem mit intuitiven Aktionen. Arbeitsweise: Wenn ein Load in keinem Cache zu finden ist, dann muss das RAM dran. Es dauert zwar übel lang, bis von da was kommt, dann aber kommen die Speicherworte sequentiell in rasendem Tempo. RAM ist heute im Grunde wie anno dunnemal ein Bandlaufwerk. Das kann man nutzen. Weshalb es nebendran noch eine Prefetch-Unit gibt. Die kriegt mit, dass nach dem RAM-Zugriff auf Adressblock N und Adressblock N+1 nun N+2 dran ist. Und vermutet ganz intuitiv, dass darauf bestimmt noch N+3 folgen wird. Und läd den z.B. schon mal vorsorglich in den L2-Cache. Etc. Die exakten Algorithmen sind natürlich Betriebsgeheimnis.
A. K. schrieb: > ist vom AVR bis rauf zum Xeon alles > erlaubt. ;-) Und wo - z.B. beim AVR (bei welchem genau) geht das?
A. K. schrieb: > Und vermutet ganz intuitiv, dass > darauf bestimmt noch N+3 folgen wird. Und läd den z.B. schon mal > vorsorglich in den L2-Cache. Etc. Die exakten Algorithmen sind natürlich > Betriebsgeheimnis. Das heisst für mich, die Optimierungen a la "C-Hater" sind obsolet, da ja der MC per se optimiert. Da wird sich C-Hater aber freuen :-) Meinst Du das wirklich ernst - für z.B. AVR?
Dieter F. schrieb: >> ist vom AVR bis rauf zum Xeon alles erlaubt. ;-) > > Und wo - z.B. beim AVR (bei welchem genau) geht das? Genausowenig wie beim 8051 oder PIC. Wer sagt, dass sich solche Techniken bereits beim AVR finden müssen? Aber beim Core i3 oder Xeon, da gibts das, und auch in deinem Handy, wenn es zur Oberklasse zählt(e).
Sven D. schrieb: > Falls Dich das Thema wirklich interessiert Beginn hier > https://de.wikipedia.org/wiki/Out-of-order_execution zu lesen, folge den > Links im Artikel und dann wiederum den Links in den verlinkten Artikeln > uswusf. Dann hast Du genug zu tun und lernst viel dazu. Wer sagt, dass ich das will? Wir sind hier in einem MC-Forum - oder? Ich schwalle auch nicht über Hyperspache oder Beamen - das gehört schlicht nicht hier her. An intuitive Maschinen-Algorithmen glaube ich nicht - predictive ja. Schon gar nicht, wenn die fest "im Blech" verankert worden sein sollen.
Dieter F. schrieb: > Wer sagt, dass ich das will? Das ist doch mal eine Aussage. Da weiss gleich jeder das Du hier im Thread nur stänkern willst.
Dieter F. schrieb: > Ich schwalle auch nicht über Hyperspache oder Beamen - das gehört > schlicht nicht hier her. An intuitive Maschinen-Algorithmen glaube ich > nicht - predictive ja. Schon gar nicht, wenn die fest "im Blech" > verankert worden sein sollen. In der Branch Prediction der in diesem Jahr kommenden Zen/Ryzen Prozessoren steckt etwas drin, das AMD als neuronales Netzwerk bezeichnet. Womit wir bei künstliche Intelligenz sind. Also zieh dich warm an, denn damit sind wir schon verdammt dicht an Intuition dran. ;-)
> Gibt es eine optimale Maschinensprache (Mikrocontroller, > Mikroprozessor), die auf der einen Seite minimale Ressourcen (z. B. des > FPGAs) benötigt und auf der anderen eine hohe Rechenleistung bietet? > Kennt jemand eine Studie, die sich dieses Themas angenommen hat? Ich glaube diese Frage ergibt keinen Sinn. Eine Maschinensprache umfasst einfach alle Befehle einer Maschine. Da gibt es nichts zu optimieren.
dd schrieb: > Ich glaube diese Frage ergibt keinen Sinn. Eine Maschinensprache umfasst > einfach alle Befehle einer Maschine. Da gibt es nichts zu optimieren. Doch, natürlich. Nämlich die Maschinendefinition. Mit welcher ISA/Maschinensprache sie ausgestattet sein sollte, um dem Ziel der Optimierung (Preis,Leistung,Strom,...) möglichst nahe zu kommen.
A. K. schrieb: > In der Branch Prediction der in diesem Jahr kommenden Zen/Ryzen > Prozessoren steckt etwas drin, das AMD als neuronales Netzwerk > bezeichnet. Womit wir bei künstliche Intelligenz sind. Also zieh dich > warm an, denn damit sind wir schon verdammt dicht an Intuition dran. ;-) Ja, nimm Dir einen Trichter, etwas Alu-Folie und bau Dir einen Hut draus :-) Hilft wahrscheinlich :-)
Mark B. schrieb: > Flieger schrieb: >> mov rx,ry kann auf OOO MAschinen 0 Takte brauchen > > Hm, wie das? Verschwindet im Register renaming was eine OOO-Maschine sowieso haben muß.
Sven D. schrieb: > Das ist doch mal eine Aussage. Da weiss gleich jeder das Du hier im > Thread nur stänkern willst. Was willst Du denn? Und welchen Beitrag leistest Du denn (außer stänkern :-) )
Dieter F. schrieb: > Ja, nimm Dir einen Trichter, etwas Alu-Folie und bau Dir einen Hut draus > :-) Hilft wahrscheinlich :-) Und den soll ich dir dann zum Schutz vor intuitiv arbeitenden AVRs schicken? Aber mein Aluvorrat ist noch aus dem letzten Jahrtausend, ich brauch davon nicht so viel - also ich weiss nicht ob das noch funktioniert.
Herbert schrieb: > Gibt es eine optimale Maschinensprache (Mikrocontroller, > Mikroprozessor), die auf der einen Seite minimale Ressourcen (z. B. des > FPGAs) benötigt und auf der anderen eine hohe Rechenleistung bietet? A. K. schrieb: > In der Branch Prediction der in diesem Jahr kommenden Zen/Ryzen > Prozessoren steckt etwas drin, das AMD als neuronales Netzwerk > bezeichnet. Womit wir bei künstliche Intelligenz sind. Also zieh dich > warm an, denn damit sind wir schon verdammt dicht an Intuition dran. ;-) Damit ist alles gesagt.
A. K. schrieb: > Und den soll ich dir dann zum Schutz vor intuitiv arbeitenden AVRs > schicken? Nein - denn die gibt es nicht (es sei denn, Du beweist mir das Gegenteil) Da gilt nur für Deine "Visionen" ... :-)
Dieter F. schrieb: > Nein - denn die gibt es nicht (es sei denn, Du beweist mir das > Gegenteil) Also ein AVR mit OOO Execution und ein paar weiteren Feinheiten in einem FPGA, das tät wohl schon reinpassen. Vielleicht auch mit 4xSMT, das wär doch wirklich ein Gewinn.
A. K. schrieb: > dd schrieb: >> Ich glaube diese Frage ergibt keinen Sinn. Eine Maschinensprache umfasst >> einfach alle Befehle einer Maschine. Da gibt es nichts zu optimieren. > > Doch, natürlich. Nämlich die Maschinendefinition. Mit welcher > ISA/Maschinensprache sie ausgestattet sein sollte, um dem Ziel der > Optimierung (Preis,Leistung,Strom,...) möglichst nahe zu kommen. hm ok - so habe ich das noch nicht betrachtet.
Es sind viele Optimierrungen und Anforderungen denkbar, die je nach Problemstellung andere Loesungen bringen. Davon ist ein orthogonaler Befehlssatz nur ein kleinraeumiger Ansatz. Sparc zB hatte glaub 32 Registerbanke. Bei einem Kontextswitch, im Wesentlichen ein Interrupt, der auch ein Taskwechsel bedeuten kann, wird einfach der Registersatz, per Index, umgeschalten, und man spart sich den Push/pop Register Save Mechanismus. Die 32 Stueck fuer 32 Interrupts waren damals gut, heut etwas wenig. Wenn man die in den Cache verlagerte.. So ein Konstrukt ist optimal fuer eine interruptlastige Maschine. DSP Maschinen haben den speziellen MAC (Multiply-Add) Befehl, der effizent eine Variable mit einer konstanten nultipliziert und sukzessiv addiert. So kann man einen Variablenvektor mit einem Koeffizientenvektor multiplizieren, wenn man da noch die DMA Maschine aufsetzt So ein Vorgang ergibt einen Befehl und wird im Hintergrund abgespult.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.