nanoController :D
-
Wenn Minimalismus, dann eine Turingmaschine.
-
Hauptmann schrieb:
Sprungbefehle:
meinst du
mov Sprunmarkenö, is ein bisschen anderse gemeint. die position an der das programm gerade abgearbeitet wird ist ja einfach ein pointer in den speicher und die jmp befehle auf normalen prozessoren setzen diese register einfach auf die adressen der sprungmarke... aber wenn man per mov auf den code pointer zugreiffen kann dann kamm man sich die sprungbefehle sparen...
das wär dann halt sowas in der art:
mov codepoointer, Sprungmarke
-
Verstehe irgendwie nicht ganz, was diese andere Schreibweise bringen soll.
"jmp Dest" und "mov ip,dest" bewirken das selbe. (selber OpCode - unterschiedliche Mnemonics)
"jmp Dest" finde ich aber einfach praktischer=>man sieht auf einen Blick, dass hier zu einer anderen Stelle im code gesprungen werden soll, was bei "mov ip,dest" nicht unbedingt der Fall ist.Um es nochmal deutlich zu sagen:
Wenn du statt "jmp Dest" "mov ip,dest" schreibst, sparst du gar nichts!
-
Um es nochmal deutlich zu sagen:
Wenn du statt "jmp Dest" "mov ip,dest" schreibst, sparst du gar nichts!ich habe ja eigentlich nur darauf hingeweisen, dass man sich einen prozessorbefehl für einen sprung sparen kann, wenn man per mov in den codepointer schreiben darf (alle architekturen die ich bisher gesehen habe haben extra befehle für sprünge)... klar ein assembler könnte trozdem noch das mnemonic jmp kennen, aber er übersetzt es ja dann trotzdem in ein mov.
-
dafür must du die ansprechbare Registerliste um den ip erweitern und verlierst so eins von deinen
16 general purpose Registern. Diese sind glaube ich vom Wert höher einzuschätzn als eine gesparter
Befehl. Die Zahl 16 kam von dir damit 2 Register in ein Byte passen.
An die Turing Antwort traut sich wohl keiner ran Bei Add und Sub bietet sich auch eine 3 Register Lösung an:
add INregister1, INregister2, OUTregister
add INregister1, INregister2, OUTregister
Dies könnte auch für andere deiner Befehle gelten.Hab so eine Lösung im Bereich der Signalprocesoren gesehen, führt dort zu einer hohen Mathe-lesitung
-
PAD schrieb:
An die Turing Antwort traut sich wohl keiner ran Das unendlich Band ist so unpraktisch
Aber ansonsten dürfte das Ding nicht allzukomplex seinBei Add und Sub bietet sich auch eine 3 Register Lösung an:
add INregister1, INregister2, OUTregister
add INregister1, INregister2, OUTregister
Dies könnte auch für andere deiner Befehle gelten.Hab so eine Lösung im Bereich der Signalprocesoren gesehen, führt dort zu einer hohen Mathe-lesitung
Unbedingt, nicht nur Mathe-Leistung. Wer mal x86 udn Sparc assembelr programmiert hat, weiß was für ein Vorteil solche Befehle sind.
-
Die Frage war:
ich stell mir grad die frage wie so ein unheimlich minimaler microprozessor aussehen könnte (anzahl register, befehle...)
Meine Antwort ist da immer noch Turing. 
ob das die sinnvollste Implementierung ist, ist eine ander Frage, vielleicht sollte man den zweiteinfachsten Processor bauen.Außerdem steht ja auch unheimlich in der Frage.
-
PAD schrieb:
Die Frage war:
ich stell mir grad die frage wie so ein unheimlich minimaler microprozessor aussehen könnte (anzahl register, befehle...)
Meine Antwort ist da immer noch Turing. Die minimalste ist immernoch der ONE INSTRUCTION SET COMPUTER (s.o
). Keine Befehlsdecodierung, man braucht intern drei Register (IP, OpA, OpB), eine Subtraktionseinheit (OpA-OpB), einen Inkrementer für IP. Ein Befehl. Das Ding soltle sich grob auf eine Schriebtischunterlage zeichnen lassen 
Für eine Turingmaschine brauchst du da mehr
-
Gebe mich geschlagen habe OISC als RISC gelesen und nicht weiter beachtet.
PS und das funktioniert?
-
PAD schrieb:
Gebe mich geschlagen habe OISC als RISC gelesen und nicht weiter beachtet.
PS und das funktioniert?jop, soll turing-vollständig sein