Welcher Mikrocontroller hat den kleinsten Befehlssatz?

PIC10F200

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

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

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

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

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?

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

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

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

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?

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.