Ich suche eine Liste, bei der die Anzahl der Instruktionen der
verschiedenen CPU Architekturen verglichen wird.
Klar, für einen 8 Bit breiten Prozessor könnte man natürlich 2^8 = 256
verschiedene Instruktionen verwenden, aber oftmals ist es ja so, dass
man für spätere Generationen noch Reserven einplant und zu Beginn gar
nicht alle benötigt und jedes weitere Bit breitere Leitungen erfordert
und das kostet wiederum Transistoren und Platz, insofern macht es
durchaus Sinn, die Anzahl an verschiedenen Instruktionen gering zu
halten.
Hier interessiert mich daher auch die Mindestanzahl an Instruktionen für
die jeweiligen Architekturen und zwar nicht in der Form, was man minimal
verwenden könnte, wenn man auf bestimmte vorhandene Instruktionen
verzichtet, sondern die tatsächliche Anzahl an verschiedenen
Instruktionen die eine bestimmte CPU Architektur hat bzw. in ihrer
ursprünglichen Form mal hatte. Also für den Fall, das etwas dazu
gekommen ist.
Ebenfalls würde ich noch gerne wissen, wie hoch diese Mindestanzahl ist,
wenn man nur die Instruktionen für das Schreiben von Userspace
Programmen verwenden würde, sofern eine Trennung in Kernel und
Userprozess auf der jeweiligen Architektur Sinn macht.
Ein Userspace Programm dürfte bspw. keine Instruktion zum Rebooten der
CPU benötigen, denn das ist Aufgabe des Kernels. Also wäre das für einen
Userprozess schon einmal eine Instruktion weniger.
Gibt es eine solche Vergleichsliste irgendwo?
Und konkreter gefragt. Gibt es Binaries, die maximal nur 26 verschiedene
Opcodes haben? Letzteres ist natürlich auch eine Frage des Compilers,
das ist klar, aber ich frage trotzdem mal.
Was meinst du hier mit "CPU Architekturen"?
Eine genaue aussage wirst du mit so allgemeinen begriffen nicht wirklich
bekommen weil schon verschiedenen Modelle einer zusammengehörigen
Modellserie unterschiedliche Befehlssätze haben können. Es gibt sogar
Architekturen wo die Länge der Opcodes variabel sein kann.
Dazu kommen auch noch unterschiedlichen Phil. die den verschiedenen
Modellen zu grunde liegen die du dir vielleicht erstmal ansehen
solltest:
RISC vers. CISC:
https://de.wikipedia.org/wiki/Reduced_Instruction_Set_Computerhttps://de.wikipedia.org/wiki/Complex_Instruction_Set_Computer
(Und heutzutage öfters auch mal ein wilder Mix aus beiden Welten:-)
Was ich so kenne war der 6502 der mit dem übersichtlichsten(kürzesten)
Befehlssatz. Ausgeufert ist das mit den Befehlssätzen dann mit der 680x0
Serie (und ich habe es aufgegeben die zu versuchen in Assembler zu
Programmieren und bin zu c/C++ gewechselt).
https://de.wikipedia.org/wiki/MOS_Technology_6502https://de.wikipedia.org/wiki/Motorola_68000#Architektur_und_Befehlssatz
Mit dem unteren Teil deiner Frage komme ich so garnicht zurecht. Da mixt
du gleich noch verschiedene Eigenschaften die vorrangig von OS verwendet
werden und garnicht von allen CPU-Architekturen unterstützt werden. Und
dann bist du plötzlich auch noch bei Hochsprachen...
Irgendwer schrieb:> Was meinst du hier mit "CPU Architekturen"?
x86 ist eine Architektur. Der Befehlssatz für den 8086 dann wohl der
kleinste gemeinsame Nenner.
Die anderen späteren Varianten, bei denen der Befehssatz um zusätzliche
Instruktionen erweitert wurde, kann also ignoriert werden, denn die sind
für meine Frage nicht relevant.
> Dazu kommen auch noch unterschiedlichen Phil. die den verschiedenen> Modellen zu grunde liegen die du dir vielleicht erstmal ansehen> solltest:> RISC vers. CISC:> https://de.wikipedia.org/wiki/Reduced_Instruction_Set_Computer> https://de.wikipedia.org/wiki/Complex_Instruction_Set_Computer> (Und heutzutage öfters auch mal ein wilder Mix aus beiden Welten:-)
Muss ich nicht.
Erstens kenne ich den Unterschied und zweitens steht da die Antwort
nicht drin, schließlich geht es um konkrete Architekturen und nicht um
Design Philosophien.
> Was ich so kenne war der 6502 der mit dem übersichtlichsten(kürzesten)> Befehlssatz. Ausgeufert ist das mit den Befehlssätzen dann mit der 680x0> Serie (und ich habe es aufgegeben die zu versuchen in Assembler zu> Programmieren und bin zu c/C++ gewechselt).
In dem Fall wäre der 6502 der kleinste gemeinsame Nenner.
Sofern die 68K Reihe zu dem abwärtskompatibel ist, was ich nicht weiß,
ich habe mit keinem von den beiden programmiert.
> Mit dem unteren Teil deiner Frage komme ich so garnicht zurecht. Da mixt> du gleich noch verschiedene Eigenschaften die vorrangig von OS verwendet> werden und garnicht von allen CPU-Architekturen unterstützt werden.
Das war von meiner Frage abgedeckt.
Siehe dazu folgender Satz:
"sofern eine Trennung in Kernel und
Userprozess auf der jeweiligen Architektur Sinn macht."
Da ist schon inkludiert, dass eine bestimmte CPU Architektur solche OS
Sachen nicht zwingend unterstützen muss, wenn es dort keinen Sinn macht.
Bsp:
"add" ist wichtig für den Userspaceprozess
und
"rst" ,welches in dieser Pseudoarchitektur für reboot bzw. restart
stehen soll, nicht und kann daher für einen Mikroprozessor, der kein OS
hat und nicht mehr Software neu gestartet werden können soll,
weggelassen werden.
> Und> dann bist du plötzlich auch noch bei Hochsprachen...
Weil man natürlich auch einen Compiler schreiben kann, der sich aus der
Menge M an verfügbaren Assemblerbefehlen mit der Teilmenge N begnügt.
Und der Assembler wandelt das dann 1:1 in Opcodes um, insofern
entscheidet der Compiler woraus diese Teilmenge besteht.
Gründe warum man das machen könnte gibt's einige.
Nano schrieb:> Klar, für einen 8 Bit breiten Prozessor könnte man natürlich 2^8 = 256> verschiedene Instruktionen verwenden,
Nein, das ist eher unnatürlich, der Instructionscode ist in der Regel
breiter als der Datenbus, was man entweder durch mehrere Buszyklen zum
Holen eines Opcodes ausgleicht (bspw i4004) oder ohnehin Instructions-
und datenspeicher trennt (aka Harvard-architectur).
Die breite eines Befehlwortes wird im allgemeinen bestimmt durch:
bits für die Codierung der Adresse des Zieloperanden,bits für die
Codierung der Adresse des Zieloperanden,
bits für die Codierung der Adresse des Zieloperanden, (bspw R0..R15)
bits für die Codierung der Adresse des sourceoperanden, (bspw. Adress
zum speicher)
bits für die Codierung der Operation auf sourceoperanden (XOR,ADD,...)
Dazu kommen gerne noch bits für Addressierungsart (indirekt) etc, hier
kommt dann auch die MMU für den Zugriffsschutz zu und der
Operandenlänge.
ARM hat schon fast Mühe alles in 32bit unterzubringen um bei
Single-cycle zu bleiben.
Insgesamt ein eher komplexes Thema; da ein brauchbare Darstellung:
ISBN: 978-0-12-811905-1. Die Unibibliothek sollte auch eine
deutschsprachige Übersetzung parat haben, ältere Auflagen sind auch ganz
passabel.
Nano schrieb:> Gibt es Binaries, die maximal nur 26 verschiedene> Opcodes haben?
Natürlich gibt es das, warum auch nicht?
Für kommerzielle Prozessoren mag das vielleicht wenig sein, aber im
Softcore-Bereich (FPGAs) ist es doch nicht unüblich nur wenige Befehle
zu haben um den Ressourcenverbrauch klein zu halten.
Solche Prozessoren können auch alles berechnen.
Beispiel:
https://de.wikipedia.org/wiki/PicoBlaze
Die Basisvariante hat genau 26 Befehle... und NOP :)
Nano schrieb:> Ich suche eine Liste, bei der die Anzahl der Instruktionen der> verschiedenen CPU Architekturen verglichen wird.
Sinnarm. Zählen
ld a, #1 MVI
ld a, b MOV
ld a, (hl) MOV
ld a, (bc) LDAX
ld a, var LDA
als 4 verschiedene Befehle (Opcode), oder bei Zilog Z80 als einer und
bloss bei Intel 8080 als 4 (Schreibweise)? Sind
ld a, (hl)
ld a, (bc)
zwei verschiedene Befehle (Codierung) oder einer (abstrakte Funktion)?
PS: Z80 ist eine erweiterte 8080, Alle diese Befehle existieren
identisch bei beiden. Zilog nennt sie nur anders.
> Gibt es eine solche Vergleichsliste irgendwo?
Vermutlich nicht.
Es gibt diverse CPUs die mit 1 Instruktion auskommen:
https://en.m.wikipedia.org/wiki/One_instruction_set_computer
Die Metrik "Anzahl der Instruktionen" ist nicht besonders sinnvoll, weil
sie kaum eindeutig definierbar ist und es auch keine sinnvolle
"besser"-Ordnung gibt. Eine CPU mit 50 Instruktionen muss nicht besser
oder schlechter als eine mit 51 sein. Oder würdest du Autos anhand der
Anzahl an verbauten Schrauben vergleichen?
Nano schrieb:> Letzteres ist natürlich auch eine Frage des Compilers, das ist klar,> aber ich frage trotzdem mal.
Und dann gibt es noch:
https://github.com/xoreaxeaxeax/movfuscator
Warum eigentlich ausgerechnet 26?
Andi schrieb:> Es gibt CPU Architekturen mit nur einer einzigen Instruktion. Viel> weiter runter kannst du nicht.> https://en.wikipedia.org/wiki/One_instruction_set_computer#Subtract_and_branch_if_negative
Ein OPC ist ein bißchen wenig, ich glaube nicht das man mit
subleq a, b, c ; Mem[b] = Mem[b] - Mem[a]
weitkommt, wenn Mem[] nicht vorher passend initialisiert ist.
Store von literals, immediates sollte da auch schon dabei sein.
IRQ statt polling ist IMHO auch kein Luxus, während man auf den vielen
CISC Zucker (Index indirekte addressierung etc.) wie beim MC68020
verzichten kann,
resp der MMU überlässt.
Gatter Stanzer schrieb:> wenn Mem[] nicht vorher passend initialisiert ist.
Man kann alle Speicherstellen mit 1 initialisieren oder mit 1,2,3,...
den Rest kann man damit on-demand berechnen.
Nano schrieb:> Gibt es Binaries, die maximal nur 26 verschiedene Opcodes haben?MSP430 hat 27 Instruktionen (siehe Kapitel 3 von
http://www.ti.com/lit/pdf/slau144), aber DADD wird von keinem Compiler
generiert.
(Eine Unterscheidung Kernel-/User-Space gibt es bei einem so kleinen
Embedded-Prozessor nicht, und dank Memory Mapping braucht er keine
I/O-Instruktionen.)
Dr. Sommer schrieb:> Gatter Stanzer schrieb:>> wenn Mem[] nicht vorher passend initialisiert ist.>> Man kann alle Speicherstellen mit 1 initialisieren oder mit 1,2,3,...> den Rest kann man damit on-demand berechnen.
Alles '1' klingt schon mal passender als alles '0', wobei ich damit
nicht die Kreiszahl pi oder andere transzendente Zahlen erst mit
Sequenzen einer einzelnen Instruction bestimmen will, bevor die
eigentliche Berechnung beginnt.
Nano schrieb:> Klar, für einen 8 Bit breiten Prozessor könnte man natürlich 2^8 = 256> verschiedene Instruktionen verwenden
Milchmädchenrechnung!
Es gibt immediate Ladebefehle, da steht der zu ladende Wert mit eim
Opcode.
Und es gibt verschiedene Addressierungsarten, da steht Addressen (von
Registern) mit im Opcode.
Gatter Stanzer schrieb:> Alles '1' klingt schon mal passender als alles '0', wobei ich damit> nicht die Kreiszahl pi oder andere transzendente Zahlen erst mit> Sequenzen einer einzelnen Instruction bestimmen will
Und wie machst du das bei "normalen" Architekturen? Da kann man pi auch
nur approximieren. Man braucht so halt nur ein paar Takte mehr zum
Literals laden. Am Ende ist es turing-vollständig, und das zählt...
Gatter Stanzer schrieb:> Ein OPC ist ein bißchen wenig, ich glaube nicht das man mit> subleq a, b, c ; Mem[b] = Mem[b] - Mem[a]>> weitkommt, wenn Mem[] nicht vorher passend initialisiert ist.> Store von literals, immediates sollte da auch schon dabei sein.
Jeder Prozessor muss Konstanten und Daten zum Programm irgendwie
speichern. Ob das nun in Immediate-Bitfeldern innerhalb des
Instruktionswortes geschieht, oder separat im Speicher mit einem Zeiger
darauf in der Instruktion, ist doch egal. Diese initialisierten Daten
sind halt Teil des Programms.
Diese SUBLEQ Instruktionen sind natürlich überhaupt nicht
speichersparend, auch wenn kein Opcode-Feld benötigt wird. Es müssen
immer 3 Adressen gespeichert werden, obwohl vor allem die Sprungadresse
nur selten gebraucht wird. Ausserdem müssen schon die einfachsten ALU
Operationen mit mehreren Instruktionen emuliert werden (ausser SUB
natürlich).
Nano schrieb:> Gibt es Binaries, die maximal nur 26 verschiedene> Opcodes haben?
Wozu soll das gut sein?
Willst Du die Mnemonics durch die 26 Buchstaben ersetzen?
Andi schrieb:> Es gibt CPU Architekturen mit nur einer einzigen Instruktion. Viel> weiter runter kannst du nicht.> https://en.wikipedia.org/wiki/One_instruction_set_computer#Subtract_and_branch_if_negative>
Das wusste ich nicht.
Könnte man damit eine CPU mit wenigen ICs der 74xx Familie bauen? Die
Komplexität kann bei nur einer Instruktion ja nicht all zu hoch sein.
Aber gut, das ist jetzt ein anderes Thema.
Dr. Sommer schrieb:> Und dann gibt es noch:> https://github.com/xoreaxeaxeax/movfuscator
Es ist immer wieder überraschend, was es allso so gibt.
> Warum eigentlich ausgerechnet 26?
Das hat einen ganz einfachen Hintergrund.
Ich habe hier ein kleines Bild in einem PNG Format mit 256 Graustufen
und das Bild hat eine nahezu einheitlich graue Fläche.
Allerdings ist es bei genauerem Blick gar nicht so einheitlich, da die 5
niederwertigsten Bit sich leicht unterscheiden.
Ich vermute bzw. könnte mir vorstellen, dass in diesem Bild per
Steganografie weitere Informationen gespeichert sein könnten.
Normalerweise würde man eine Datei ja packen, dann vielleicht noch
verschlüsseln und die Daten dann irgendwie mit einem
Steganografieverfahren über die einzelnen Pixel im Bereich der
niederwertigen Bits aufteilen, allerdings gibt es in diesem Bild nur 26
verschiedene Farbwerte, obwohl die 5 Bits 2^5 Bits = 32 unterschiedliche
Werte erlauben würde.
In Binärform werden von den letzten niederwertigen Bits also nur Werte
bis bis 11001 genutzt, nicht aber bis 11111.
Nun könnte man ja die Annahme treffen, dass Werte über 11001 zu sehr
auffallen, aber logischer wäre ja eigentlich, das man der Einfachheit
halber lieber ein Bit weniger nimmt und nur die Niederwertigen Bits bis
1111 verwendet. Das wäre auch von der Programmierung deutlich einfacher,
aber in dem Bild werden halt 5 niederwertige Bits verwendet, die mit der
niederwertigen Bitfolge 00000 maximal 26 unterschiedliche Werte
darstellen.
Da das Bild aber von einer Programmierseite ist, kam mir eine neue Idee.
Vielleicht werden da gar nicht beliebige Daten per
Steganografiealgorithmus über die 5 niederwertigen Bits aufgeteilt,
sonder vielleicht hat er da einfach Opcodes steganografisch versteckt.
Architekturen, die nur 26 Opcodes haben könnte es ja geben. Das war
meine Überlegung.
All das natürlich gesetzt den Fall, dass das Bild überhaupt
Steganografie enthält.
Dafür spricht, dass
1. eine graue Fläche dargestellt wird, die ohne das Bild zu vergrößern
wie eine einheitliche Fläche aussieht.
2. Man für das Dateiformat ein verlustfreies Format, nämlich PNG
verwendet.
3. das Bild Rauschen enthält.
4. Das Rauschen sich in den 5 niederwertigsten Bit befindet.
5. Das Bild Teil einer Webseite ist.
Diese 5 Punkte könnten ein Indiz für Steganografie sein, denn
normalerweise würde für eine einheitliche Fläche, die man mit bloßem
Auge als solche wahrnehmen möchte, ja ein einziger Farbton für alle
Pixel genügen.
Und zweites ließe sich so etwas dann auch wesentlich besser komprimieren
als ein Rauschen in den 5 niederwertigsten Bit.
Zumal kleinere Dateien auch die Ladezeit verkürzen würde und
Traffickosten sparen würde.
Aufgefallen ist mir das Bild übrigens nur durch Zufall als ich die
Webseite besuchte.
Ich war an meinem großen TV surfen und bei ausschließlich dieser
Webseite hatte ich bei deren grauen Hintergrund ein seltsames Flackern
oder einen Moire Effekt.
Wenn ich die Seite in FF mit "ALT GR" + "+" vergrößerte oder mit "ALT
GR" + "-" verkleinerte, dann war das flackern plötzlich weg.
Eine genauere Untersuchung führte mich dann zu diesem grauen Bild,
welches gar nicht aus einem einheitlichen Grauton besteht, sondern eben
aus Rauschen in den 5 niederwertigsten Bit.
Es ist natürlich auch gut möglich, dass in diesem Bild eine Signatur
oder ein Wasserzeichen mithilfe von Steganografie versteckt ist.
Clemens L. schrieb:> MSP430 hat 27 Instruktionen (siehe Kapitel 3 von> http://www.ti.com/lit/pdf/slau144), aber DADD wird von keinem Compiler> generiert.
Danke für die Info. Diese Architektur könnte da also schon einmal
hinkommen.
Udo S. schrieb:> Es gibt immediate Ladebefehle, da steht der zu ladende Wert mit eim> Opcode.> Und es gibt verschiedene Addressierungsarten, da steht Addressen (von> Registern) mit im Opcode.
Ja, ich bin hier davon ausgegangen, dass der Opcode von den Operanden
getrennt bearbeitet wird.
Ach noch eine kleine Ergänzung.
Auf meinem Computerbildschirm hatte ich kein Flackern und auch keinen
solchen Moire Effekt bei dieser Webseite.
Dass mir das am TV aufgefallen ist, war also reiner Zufall.
Nano schrieb:> Ja, ich bin hier davon ausgegangen, dass der Opcode von den Operanden> getrennt bearbeitet wird.
Daß bei Deiner grauen Fläche die Operanden sich aus dem gleichen
"Werteumfang" wie die Opcodes bedienen müssen, ist Dir entgangen?
Rufus Τ. F. schrieb:> Nano schrieb:>> Ja, ich bin hier davon ausgegangen, dass der Opcode von den Operanden>> getrennt bearbeitet wird.>> Daß bei Deiner grauen Fläche die Operanden sich aus dem gleichen> "Werteumfang" wie die Opcodes bedienen müssen, ist Dir entgangen?
Ja, bzw. könnten das ja auch kleine Werte sein.
Das Muster in lesbaren Text konvertieren schon mal probiert?
Es macht m.E. keinen Sinn eine kastrierte Opcode-Geschichte für einen
wildfremden Prozessor im Bild zu verstecken.
Der Text ist evtl. nochmal kodiert, z.B. per ROT13 o.ä.
Vielleicht ist da aber auch was lesbares drin.
Jens M. schrieb:> Das Muster in lesbaren Text konvertieren schon mal probiert?
Für Unix Systeme und Linux gab es ein Tool mit dem man solche
Steganografiesachen erstellen oder auch danach suchen kann.
Das wollte ich demnächst mal einrichten, bin dazu aber noch nicht
gekommen.
Der nächste Schritt wäre, aus den 5 niederwertigen Bits einen
zusammenhängenden Bytestrom zu machen und mal sehen, ob da etwas
sinnvolles bei rauskommt. Aber dazu bin ich auch noch nicht gekommen.
Prinzipiell gibt es sehr viele Arten, solche Bits auszuwerten und zu
bearbeiten, das gleicht der Suche nach einer Nadel im Heuhaufen.
Dieses bestehende Steganografieprogramm an der Bilddatei auszuprobieren
ist daher meine beste Option.
Momentan beschäftige ich mich mit dem Win Update Problem, siehe der
andere Thread. Das hat Priorität.
