Umstieg von CISC auf RISC µC

[Z003 (Gast)]

Guten Morgen,

ich schreibe gerade meine Abschlussarbeit und muss für ein bestehendes 
Projekt einen neuen Mikrocontroller auswählen.

Nun geht es um den Wechsel von CISC auf RISC.

Meine Recherche hat folgendes ergeben:
Bei RISC ist der Befehlssatz beschränkt bzw. besitzt einen deutlich 
geringeren Umfang. Dies spielt für mich jedoch nur eine Rolle, wenn ich 
in Assembler programmiere.

Bisher wurde der M16C von Renesas verwendet, welcher die 
CISC-Architektur besitzt. Nun dürfte es kein Problem sein, einen 
RISC-Prozessor zu verwenden (geplant ist der STM32F4), da der zum µC 
kompatible Compiler den in C geschriebenen Quellcode in die passenden 
Befehle umwandelt.

Ich wäre dankbar, wenn mir das jemand bestätigen oder mich auf Fehler 
hinweisen kann.

Grüße

[(prx) A. K. (prx)]

Z003 schrieb:
> Dies spielt für mich jedoch nur eine Rolle, wenn ich
> in Assembler programmiere.

Fast. Wenn du dich bisher darauf verlassen hast, dass
   counter += 1;
im Hauptprogramm und
   counter = 0;
im Interrupt kein Problem bereiten kann, dann wirst du Überraschungen 
erleben. Beim ARM ist diese Addition unterbrechbar, beim M16C nicht.

[Volle2 (Gast)]

Der Befehlssatz spielt aus C-Sicht keinen große Rolle
abgesehen von Float und speziellen Befehlen
Das geht aber Richtung Effizienz

Aber Adressierungsarten und Lokatierungsarten und wie ich sie aus C 
nutze
(pragmas/Atribute) ist wichtig

[(prx) A. K. (prx)]

Volle2 schrieb:
> Lokatierungsarten

Wasndas?

[Peter D. (peda)]

Neben der Unterscheidung CISC/RISC gibt es auch Von Neuman/Harward, d.h. 
ob Daten und Code im gleichen oder in getrennten Adreßräumen liegen.

[(prx) A. K. (prx)]

Peter D. schrieb:
> Neben der Unterscheidung CISC/RISC gibt es auch Von Neuman/Harward, d.h.
> ob Daten und Code im gleichen oder in getrennten Adreßräumen liegen.

Das wird in seinem Fall aber nur einfacher, bei M16C => ARM, weil die 
Klimmzüge zur Flashadressierung entfallen.

[A. S. (Gast)]

Deine Überlegungen sind im embedded-Bereich (µController) sinnlos.

Ja, den reinen ANSI-C-Teil kann der neue Compiler vermutlich wie der 
alte übersetzen. Daneben gibt es aber noch in SW:

#pragmas

#implementation defined behaviour (und wie z.B. beim Überlauf von ints; 
UB.)

#Interrupts
#Lock-Mechanismen
#Betriebssysteme/Libraries/...
#int-größen
#endianess

die alle irgendwie anders sein können, oder in HW:

- integrierte Peripherie (Clock, ADCs, Timer, ...), sonst wäre es ein 
Prozessor, keine µController.
- Register-Mapping
- Schreiben/Lesen interner Speicher
- atomare Operationen (oder nicht),


RISC oder CISC ist manchmal nur ein Indiz dafür, wie weit einige dieser 
Punkte voneinander abweichen.

[Z003 (Gast)]

A. K. schrieb:
> Beim ARM ist diese Addition unterbrechbar, beim M16C nicht.

Danke, merke ich mir für die Programmierung.

Peter D. schrieb:
> Neben der Unterscheidung CISC/RISC gibt es auch Von Neuman/Harward, d.h.
> ob Daten und Code im gleichen oder in getrennten Adreßräumen liegen.

Ja, das habe ich bereits beachtet. Danke für den Hinweis.

[Z003 (Gast)]

Achim S. schrieb:
> Ja, den reinen ANSI-C-Teil kann der neue Compiler vermutlich wie der
> alte übersetzen.

Es geht ja aktuell erst einmal darum, ob der neue µC verwendet werden 
kann.  Viele Punkte die du ansprichst müssen - soweit ich das verstehe - 
dann bei der Anpassung der Software beachtet werden.

Achim S. schrieb:
> - integrierte Peripherie (Clock, ADCs, Timer, ...), sonst wäre es ein
> Prozessor, keine µController.

Wurde bei der Auswahl des µC beachtet.

Achim S. schrieb:
> - Register-Mapping
> - Schreiben/Lesen interner Speicher

Sind das nicht auch Software-Themen?