Hallo Alle, jeder Mikrocontroller hat seinen eigenen Befehlssatz. Ein AVR hat so um die 120 Assemblerinstruktionen. Welcher Mikrocontroller den Ihr kennt, hat die kleinste Anzahl von Assemblerbefehlen? Für welchen Mikrocontroller wäre es am einfachsten, einen Simulator in C zu schreiben?
Die gute alte C64-CPU. 56 Befehle. Naja, ist ein Mikroprozessor und kein -controller, aber trotzdem konnte er alles. Übrigens auch nur eine sehr kleine Anzahl von Registern. Ein Akku und zwei Indexregister reichen aber scheinbar auch, um Bubble Bobble zu spielen.
Das würd ich daran nicht festmachen und hängt sehr stark davon ab, wie man zählt. Sonst schau dir mal den ARM Befehlssatz an, der ist in nur wenige Befehle unterteilt - Branches - SWI - Arithmetic - MUL/MULL - MCR/MRC - CP - LDR/STR - LDM/STM (hab ich was vergessen) Und trotzdem nicht wirklich flott um nen Simu-/Emulator zu implementieren. Ich verweise gerne auf desmume (und andere NDS Emus), wenn du dir eine einfache und (recht) zuverlässige Core-Emulation mal anschauen willst.
Der hier: http://www.wolfgang-back.com/knowhow_home.php ist zwar kein Mikrocontroller, dafür gibts den Simulator auch schon ;) Oliver
wie tt2t schon sagt, die PICs haben mit 33 schon sehr sehr wenig. Noch weniger (nur 8 !! ) hat der hier: http://www.masella.name/technical/BF-CPU.pdf
Christoph schrieb: > Für welchen Mikrocontroller wäre es am einfachsten, > einen Simulator in C zu schreiben? Ich glaube das hängt nicht unbedingt nur von der Größe des Befehlssatzes sondern auch von der internen Struktur des µC/Prozessor ab. Eine recht einfache Struktur hat die MIC-1, die haben wir im Studium mal behandelt. Ist aber erstmal kein "echter" µC/Prozessor, den man irgendwo als einzelnen IC kaufen kann (soweit ich weiß).
Ein kleinerer, einfacherer Befehlssatz fuehrt zu mehr Code. Daher ist ein einfacherer Befehlssatz nicht unbedingt ein Vorteil. Ebenso fuehrt eine einfachere Architektur zu mehr code. Der 8051 hatte ein Pointer Register. Alles darueber machen zu muessen ist elend muehsam. Da ist ein AVR mt 3 pointern schon viel besser.
Christoph schrieb: > Welcher Mikrocontroller den Ihr kennt, hat die kleinste Anzahl von > Assemblerbefehlen? Für welchen Mikrocontroller wäre es am einfachsten, > einen Simulator in C zu schreiben? Hi, die PIC16C / 16F in der "traditionellen" Ausstattung haben alle 35 assemblerbefehle (Nicht die enhanced Serie, die hat 49!) Wenn es um eine "Aufgabe" geht, dann würde ich davon einen gängigen kleineren Vertreter nehmen... (z.b. PIC16F84(a), 16F628) Der zitierte 10F200 hat 33 Befehle, das wirkt aber schon irgendwie deutlich ausgesucht! Für 2 Befehle würde ich dann schon eher den gängigen µC wählen. Das Stack Level, die SFR, und das eine Indexregfister für die indirekte Adressierung sind acuh nicht wirklich aufwendig. Einzigste Schweinerei ist die Bankumschaltung, bei dem 16F84 hast du z.B. zwei Speicherbänke wo auch die SFR über beide Bänke verteilt sind. Vorteil allerdings: Wenn du einen 16F Emuklator schreibst, dann kannst du den auch leicht auf fast die ganze Familie aufbphren. Du musst halt nur für jeden Typ eine eigene Definitionsdatei für Speicher und peripherie anlegen. Es gibt übrigends einen Simulator in der MPLAB, der kostenlosen Entwicklungsumgebung zum PIC, damit könntest du dann deine Ergebnisse vergleichen. Gruß Carsten P.S: Der ARM hat zwar nur wenige Befehlsgruppen, aber doch einiges an Befehlen. Nicht zu vergessen das er zwei komplett getrennte Befehlssätze hat und verschiedene Registerarten. Und, und, und... Der Unterschied ARM Simulator und PIC16 Simulator ist der Unterschied wie eine mathematische Simulation für eine Kerze und einen Kernfusionsreaktor zu erstellen. Gruß Carsten
> hat die kleinste Anzahl von Assemblerbefehlen? Witzlose Frage, denn welche Syntax beim Assembler gewählt wird, hat nichts mit der tatsächlichen Befehlsanzahl zu tun. Da kann ein OR Akku,Aakku schon mal zum NOP werden, oder man teilt in MOV und LD und STORE während der Konkurrent das nicht tut. > Für welchen Mikrocontroller wäre es am einfachsten, > einen Simulator in C zu schreiben? Für einen, dessen vollständige Spezifikation du hast. Ob PIC oder AVR oder 68HC11 oder SC/MP, die sind alle nicht schwer, nur ist man vielleicht mehr als PIC interessiert als am veralteten SC/MP.
Vielen Dank für eure Antworten. >Noch weniger (nur 8 !! ) hat der hier: >http://www.masella.name/technical/BF-CPU.pdf Der scheint mir etwas Turingmaschinen-artig. Ich habe gehört, dass eine Turingmaschine mit 6 Basisinstruktionen auskommt. Eine Turingmaschine kann ja theoretisch alle Computer simulieren. Ich habe mal einen Übungsprozessor mit 16Befehlen programmiert: http://www.hobby-roboter.de/forum/viewtopic.php?p=375 Allerdings ist dieser Prozessor ziemlich umständlich zu programmieren und eher akademischer Natur. Deshalb interessiert mich eher eine etwas praktischer verwendbare Architektur.
>Der zitierte 10F200 hat 33 Befehle, das wirkt aber schon irgendwie >deutlich ausgesucht! Für 2 Befehle würde ich dann schon eher den >gängigen µC wählen. Gibt es für die Pics einen freien C-Compiler? Vielleicht sogar einen GCC-Port?
Christoph schrieb: > Allerdings ist dieser Prozessor ziemlich umständlich zu programmieren > und eher akademischer Natur. > Deshalb interessiert mich eher eine etwas praktischer verwendbare > Architektur. Dann bleibt unter berücksichtigung des Kriteriums "wenige Befehle" nur der PIC16F... Wenn auch bei leibe nicht mehr die Aktuellte Architektur doch immer noch zahlreich auch für neue Projekte im Einsatz... Anfangen würde ich mit dem PIC16F84, wobei ich da von der Struktur schon so vorgehen würde das alles was genau bei diesem Vertreter der PIC16F Familie anders als bei den anderen ist bereits in einem extra Def. File steht. Dann kann man mit im Verhältniss wenig Aufwand einen Simulator für ganz viele Proz. bauen. WOBEI: Einen echten Nutzen über deinen Lerneffekt hinaus (-wobei das ist ja schon einiges-) wirst du bei fast keinem Proz. haben. Für alle einfach händelbaren und gängigen gibt es ja bereits "einfach verfügbare" Simulatoren. Meist sogar mehr als einen... Gruß Carsten
>WOBEI: >Einen echten Nutzen über deinen Lerneffekt hinaus (-wobei das ist ja >schon einiges-) wirst du bei fast keinem Proz. haben. Für alle einfach >händelbaren und gängigen gibt es ja bereits "einfach verfügbare" >Simulatoren. Meist sogar mehr als einen... WOBEI: Allerdings die wenigsten davon auf einem AVR laufen.
Christoph schrieb: >>Der zitierte 10F200 hat 33 Befehle, das wirkt aber schon irgendwie >>deutlich ausgesucht! Für 2 Befehle würde ich dann schon eher den >>gängigen µC wählen. > > Gibt es für die Pics einen freien C-Compiler? Vielleicht sogar einen > GCC-Port? Es gibt auf jeden Fall freie Versionen der Kommerziellen Compiler, die für alle Hobbyanwendungen ausreichen. Einzige Einschränkung ist das die Codeoptimierung nicht 100% auf minimalste Codegrösse auslegt. Der Code also am ende vieleicht 10% größer ist als mit der PROFI-Version. Für den Hobbyisten und Kleinserienbauer absolut unerheblich. Wenn dann der Code drei Befehle für den kleinsten Vertreter der Familie zu groß ist, dann nimmt man den vollständig kompatiblen mit mehr Speicher für 10ct mehr. Beim Industriellen Großserienproduzenten sieht es anders aus. Wenn der Pro Chip 5ct. sparen kann in dem er eine Nummer kleiner nimmt, dann macht das bei 10000 ICs pro Tag (oder deutlich mehr) schon was aus. Dann auf den Monat, das Jahr, den ganzen Lebenszyklus des Produktes gerechnet... Ob es noch weitere völlig freie Compiler oder gar eine GCC Variante gibt, das entzieht sich meiner Kentniss. Komme mit dem HiTech einfach aus. (Wobei ich die 16F eh meist nur in Assembler Programmiere. Wenn ich C nehmen will, kommt meist direkt ein 18F zum einsatz.) Gruß Carsten
Christoph schrieb: > Welcher Mikrocontroller den Ihr kennt, hat die kleinste Anzahl von > Assemblerbefehlen? Der Motorola ICU (MC14500B) hat 16 Befehle: http://www.datasheetarchive.com/pdf/getfile.php?dir=Datasheets-21&file=DSA-411815.pdf&scan= Dürfte auch ziemlich einfach zu emulieren sein. Gruß Anja
Christoph schrieb: >>WOBEI: >>Einen echten Nutzen über deinen Lerneffekt hinaus (-wobei das ist ja >>schon einiges-) wirst du bei fast keinem Proz. haben. Für alle einfach >>händelbaren und gängigen gibt es ja bereits "einfach verfügbare" >>Simulatoren. Meist sogar mehr als einen... > > WOBEI: > Allerdings die wenigsten davon auf einem AVR laufen. Äh, ja... Das ist richtig! Aber das war bis jetzt doch auch nicht gefordert, oder? Ach, jetzt verstehe ich: Du willst einen µC (z.B. PIC) Compiler schreiben der dann in einem AVR laufen soll? Wenn das so ist, dann nimm definitiv einen PIC16F84, Da könnte es dann sogar noch den einen oder anderen Hobbyisten geben der den dann verwenden würde. Aber viel Platz nach oben ist da nicht mehr bei den gängigen µC... Dafür sind die AVRs dann wieder zu schlapp. Denn AVR und PIC spielen grundsätzlich in der selben Liga. Also kommt eh nur die Emulation eines z.N. schwachen PICs auf einem starken AVR in Frage. Und auch leistungsfähige 8051 derrivate gibt es mehr als genug. Immerhin muss der Prozessor welcher den Code mittels Compiler verarbeite ja deutlich mehr Leistung aufbringen um die Ausführung in der selben Zeitspanne ausführen zu können als das native System! Gruß Carsten
Hi, Anja schrieb: > Der Motorola ICU (MC14500B) hat 16 Befehle: > > http://www.datasheetarchive.com/pdf/getfile.php?dir=Datasheets-21&file=DSA-411815.pdf&scan= > > Dürfte auch ziemlich einfach zu emulieren sein. > > Gruß Anja Wobei das je kein µC ist. Nicht einmal ein µP! ProgramCounter, Latches, AdressDecoder, Speicher muss ALLES extern noch dazukommen. Das ist eigendlich nicht mehr als die ALU eines µP/µC als Einzelbaustein. Wobei das -A- von ALU dabei noch sehr Diskussionswürdig ist -mal vornehm ausgedrückt-. Aber Simulieren bzw, Emulieren kann man das recht einfach. Müsste doch fast noch in größeres GAL reinpassen, mal durchdenken... Gruß Carsten
Ach der MC14500B. An den erinnere ich mich noch aus den 80ern. Elektor hat glaube ich mal was damit gemacht. Gibts den denn noch zu kaufen?
>Ach, jetzt verstehe ich: Du willst einen µC (z.B. PIC) Compiler >schreiben der dann in einem AVR laufen soll? Ja, das ist das Ziel. Ich habe das mal für den 8051 Kern gemacht, der läuft auf einem Atmega16. Da ist mir aber der Code für den Emulator zu groß, deshalb suche ich nach einem Kern mit weniger Befehlen. >Wenn das so ist, dann nimm definitiv einen PIC16F84, Da könnte es dann >sogar noch den einen oder anderen Hobbyisten geben der den dann >verwenden würde. Hmm, mal schauen. PIC-User gibt es ja einige. Vielleicht wenn jemand mitmachen will. Die Anforderungen für das Projekt sind halt folgende: - kleiner Emulator Footprint - gut interpretierbare Befehle, damit das ganze nicht zu langsam wird - C-Compiler Unterstützung des Kerns Was den C-Compiler angeht, wäre die Unterstützung des GCC am schönsten, da sich dann der Code zwischen den Architekturen gut portieren lässt. Kennt jemand den MSP430? Was ist von dessen Kern zu halten?
>Ach der MC14500B. An den erinnere ich mich noch aus den 80ern. Elektor >hat glaube ich mal was damit gemacht. Gibts den denn noch zu kaufen? Den könnte man bestimmt einfach mit einem AVR emulieren.
Maxims MAXQ2000 dürfte kaum zu schlagen sein. Der hat genau 2 Befehle: move constant to register move register1 to register2 Der Rest ergibt sich aus der Wahl der Register, d.h. eines addiert, eines subtrahiert, eines schreibt in den Speicher an der vorher in einem anderen Register definierten Adresse, ...
Christoph schrieb: > Welcher Mikrocontroller den Ihr kennt, hat die kleinste Anzahl von > Assemblerbefehlen? Für welchen Mikrocontroller wäre es am einfachsten, > einen Simulator in C zu schreiben? Die Komplexität eines Simulators ist nicht so sehr abhängig von der Anzahl Befehle. Stärker geht die Komplexität der Codierung des Befehlssatzes ein, und die Problematik der Statusflags.
>Maxims MAXQ2000 dürfte kaum zu schlagen sein. Der hat genau 2 Befehle: > move constant to register > move register1 to register2 Klingt interessant, >Der Rest ergibt sich aus der Wahl der Register, d.h. eines addiert, >eines subtrahiert, eines schreibt in den Speicher an der vorher in einem >anderen Register definierten Adresse, ... Wobei ich vermuten würde, dass man dadurch die Komplexität nur in die Implementierung der Registerfunktionen auslagert, also letztendlich nichts gewinnt. >Die Komplexität eines Simulators ist nicht so sehr abhängig von der >Anzahl Befehle. Stärker geht die Komplexität der Codierung des >Befehlssatzes ein, und die Problematik der Statusflags. Das ist wohl war. Vielleicht sollte man die Frage unter diesem Gesichtspunkt stellen. Also welcher Prozessor ist in dieser Hinsicht der geeignetste?
Christoph schrieb: > Das ist wohl war. Vielleicht sollte man die Frage unter diesem > Gesichtspunkt stellen. Also welcher Prozessor ist in dieser Hinsicht der > geeignetste? Wenn nur wenige Befehle irgendwelche Auswirkung auf Flags haben ist man besser dran. Ideal ist in dieser Hinsicht, wenn abgesehen vom Carryflag überhaupt keine klassischen Statusflags verwendet werden, sondern beispielsweise auf Akku=0 getestet wird. Sehr einfach und performant simulierbar ist auch deshalb beispielsweise der olle CDP1802.
>Sehr einfach und performant >simulierbar ist auch deshalb beispielsweise der olle CDP1802. Ach, es ist doch schön, sich mal ein wenig mit Prozessorgeschichte zu befassen: http://en.wikipedia.org/wiki/RCA_1802 Man lernt doch einiges dabei. Die Anzahl der Befehle diese Prozessors ist nicht gerade gering http://homepage.mac.com/ruske/cosmacelf/cdp1802.pdf , deshalb bedeutet das Schreiben des Emualtors doch einigen Aufwand. Wobei die Emulation eines Prozessors auf einem AVR, der sich normalerweise in Raumsonden befindet, doch eine gewisse Ästhetik hätte. Ich vermute, dass die Raumsonden vornehmlich in Assembler programmiert wurden, so dass es mit einem C-Compiler dafür etwas happert.
Christoph schrieb: > Ich vermute, dass die Raumsonden vornehmlich in Assembler programmiert > wurden, so dass es mit einem C-Compiler dafür etwas happert. Yep, C Compiler gibts dafür nicht. Und Assembler-Programmierung für das Teil ist nichts für Weicheier. Es gibt nämlich keinen Unterprogrammaufruf.
Hab selbst grade einen Emulator für den 6510er auf dem AVR geschrieben. Dafür, dass ich das noch nie gemacht habe, fand ich die Sache schon ziemlich einfach so im Rückblick. Nutzen lässt sich das Ganze auch, da der AVR-IO ansprechbar ist. 1MHz-Emulation mit 16-20MHz ist sogar mit exakter 16/1 bzw. 20/1 MHZ-Taktung möglich. Ein nicht-speicher-schonendes Assemblerprogramm kommt mit <6k Flash aus. Der 6502/6510 Befehlssatz ist recht gut strukturiert und die opcodes lassen sich einfach zerlegen und verarbeiten. Dokumentation gibt's reichlich, auch wenn da einige Fehler drin sind. Assembler gibt's einige und ich meine auch Cross-Compiler. Hatte mir auch für einen weiteren Emulator den AVR-Befehlssatz mal genauer angeschaut, der ist im Gegensatz zum 6510 der reinste Horror für einen Emulator.
Carsten Sch. schrieb: > die PIC16C / 16F in der "traditionellen" Ausstattung haben alle 35 > assemblerbefehle (Nicht die enhanced Serie, die hat 49!) noch ganz wenn man die OPCodes abzieht sind es 16 echte befehle bei dem 16F bei den AVR befehlen dürfte das ähnlich sein.
Als ich die Frage gelesen habe, kam mir der F21 uP von Charles Moore (Forth) in Erinnerung. Der Prozessor kommt mit 27 Befehle aus und ist Stack basierend, eine Art mini-Forth in Hardware gegossen. Hier gibts ein paar Infos dazu: http://www.ultratechnology.com/f21data.pdf -Klaus
>kam mir der F21 uP von Charles Moore Hallo klausr, das ist auch ein interessantes Design. Die Java-JVM ist meines Wissens auch Stack basiert und erinnert in ihrer Struktur stark FORTH inspiriert. Die CPU, die Hajo weiter oben genannt hat >32! >http://greenarraychips.com/ geht wohl auch in die Richtung. Fehlt nur noch ein C nach FORTH Compiler.
Ein rudimentärer Single-Pass Compiler für eine Stack basierte Maschine ist relativ einfach zu bewerkstelligen. So einer ist z.B. im "Drachenbuch" (ISBN 978-3-8273-7097-6) beschrieben. -Klaus
Die MAXQs von Maxim haben genau einen Befehl: move (Transport Triggered Architecture) oder einfach subleq passend simulieren (sncr) http://en.wikipedia.org/wiki/OISC
>http://en.wikipedia.org/wiki/OISC
Das scheint mir ein wenig nach dem Prinzip "Aus NAND-Gattern kann man
jede beliebige logische Schaltlogik herstellen, also auch jeden
Computer".
Ich kannte diesen Typ noch nicht und finde das Prinzip sehr lehrreich.
Es gab mal eine 1-Bit-CPU (1975) und einen Controller mit 16 Befehlen und 1-Bit-ALU. Ich meine der Controller war von Motorola.
Hatten wir schon, weiter oben:
Anja schrieb:
> Der Motorola ICU (MC14500B) hat 16 Befehle:
Allerdings ist das Ding keine richtige CPU.
Hallo, falls sich doch mal jemand mit Geschichte und Theorie befasst, da sind viele Fragen längst geklärt (längst heisst so etwa seit dem letzten Weltkrieg): die Turing-Maschine hat 3 Operationen und kann bewiesenermassen alle Probleme lösen, die ein allgemeiner Computer auch lösen kann. Nur werden die Programme etwas lang. Dass die ganze Diskussion zwar interresant, aber ohne tieferen Sinn ist, ergibt sich schon daraus, dass man den Begriff "Befehlssatz" garnicht definieren kann: 1. ein Assembler-Befehl wie LD oder MOV kann je nach Parameter ganz verschiedene Maschinenbefehle auslösen, etwa LD A,22 immediate LD A,R2 register LD A,(R2) indirekt usw. der Assembler-Befehlssatz unterscheidet sich also erheblich vom Maschinen-Befehlssatz. 2. Zusammengesetzte Befehle wie LDIR (Z80) Lade indirect von (@Reg HL) in (@Reg DE) Incrementiere DE Incementiere HL Decrementier BC Springe zurück wenn BC <> 0 können genausogut durch einzelne Befehle ersetzt werden und sind daher komplett überflüssig - sie waren nur zur Arbeitserleichterung für manuelle Assemblerprogrammierung da, es ist garnicht gesagt, dass ein Compiler sie verwendet (daher der Schwenk zu den RISC-Architekturen). Und so könnte man noch vieles anführen, was beim Vergleich von Befehlssätzen zu beachten wäre. Von der konkreten Aufgabenstellung mal ganz abgesehen. Gruss Reinhard
>falls sich doch mal jemand mit Geschichte und Theorie befasst, >da sind viele Fragen längst geklärt (längst heisst so etwa seit >dem letzten Weltkrieg): die Turing-Maschine hat 3 Operationen und kann Tja, sollte man denken,dass alles geklärt ist. Welche 3 Operationen sind es denn?
Es gibt ein paar Varianten und darin ein paar verschiedene Formulierungen, beispielsweise op=schreiben(X) next=S op=links next=S op=rechts next=S um auf 3 Operationen zu kommen, alternativ auch write=X dir=L/R next=S wenn man es auf eine drücken will. Das sind zwar keine exakt gleichen Maschinen, an den mathematischen Eigenschaften ändert das aber nichts. Wie oben schon erwähnt wurde ist die Zählweise von Befehlen oder Operationen etwas willkürlich. So kommt man bei den PICs auf werbewirksame wenige Befehle, indem man vom Ablauf verschiedene Operationen per Befehlsparameter zusammenfasst, ob nämlich das Ziel im RAM oder im Akku landet. Das kann man ggf. auch anders sehen und im Assembler anders formulieren. Wenn man das exakt gleiche Programm in Zilogs Assembler ausdrückt, dann sieht man weit weniger Befehle als beim Intel Assembler der 8080, weil Zilog viel zusammengefasst hat, was Intel per Mnemonic trennte. Ähnlich beim erwähnten MAXQ. Ich hatte den oben als Maschine mit 2 Operationen bezeichnet, jemand anders später jedoch mit einer Operation. Beides ist richtig oder falsch, je nach Betrachtungsweise. Im MAXQ-Assembler gibt es nämlich weit mehr.
Hmm, wie müsste denn ein Programm für die Turing Maschine aussehen, das
die gleich Funktion wie folgendes Mikrocontroller Pseudocodeprgramm
ausführt:
while(forever)
{
portBitAusgang=PortBitEingang1 XOR PortBitEingang2
}
Reinhard Kern (Firma: RK elektronik GmbH) (rk-elektronik) schrieb >falls sich doch mal jemand mit Geschichte und Theorie befasst, >da sind viele Fragen längst geklärt (längst heisst so etwa seit >dem letzten Weltkrieg): die Turing-Maschine hat 3 Operationen Und viele Fragen sind vielleicht ziemlich ungeklärt: Eine Turingmaschine ist kein Mikrocontroller. Ein Mikrocontroller hat einen endlichen Speicher und Ein/Ausgabeeinheiten. Alleine aus diesem Grunde ist die Antwort auf die Eingangsfrage "Welcher Mikrocontroller hat den kleinsten Befehlssatz?" nicht korrekt. >Dass die ganze Diskussion zwar interresant, aber ohne tieferen > Sinn ist,ergibt sich schon daraus, dass man den Begriff > "Befehlssatz" garnicht definieren kann: Die Diskussion hat sehr wohl einen tieferen Sinn, wenn damit erreicht wird zu beschreiben, was ein "sinnvoller" Befehlssatz ist.
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.