Optimale Maschinensprache

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?
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

Eine optimale Lösung existiert generell nur für ein spezifisches 
Problem. Etwas, das für jeden beliebigen Anwendungsfall optimal ist, 
existiert nicht.

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.

Flieger schrieb:
> mov rx,ry kann auf OOO MAschinen 0 Takte brauchen

Hm, wie das?

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.

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;}

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).

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.

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:
> performanteren aber weniger effizienten A15/A53/A57/A72.

performanteren aber weniger effizienten A15/A57/A72/A73.

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.

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.

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.

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.

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.

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.

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.

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:
> 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.

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).

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. ;-)

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.

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.

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.

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.