ARM bevorzugter Betriebsmode der End-Application

Ich sehe wenig Sinn darin, auf einem Controller mit in jedem Modus 
unbeschränker Adressierfähigkeit ein paar kleine Systemfunktionen wie 
Interrupt-Steuerung über User/System Trennung einschränken zu wollen. In 
Controllern ohne MMU gibt es heutzutage keine unkontrollierten 
Anwenderprozesse, vor denen sich zu schützen es sich lohnt.

Diese Trennung ergibt erst dann wirklich Sinn, wenn der Adressraum eines 
USER Prozesses auf seine eigenen Code+Daten-Bereiche beschränkt ist, 
d.h. eine MMU verwendet wird. DANN erst entsteht durch die 
Privilegientrennung ein erhebliches Mass an Sicherheit. Die meisten 
Programmfehler entstehen in C durch unbeabsichtigten Speicherzugriff, 
nicht durch unberechtigte Interrupt-Steuerung.

Historisch gesehen hatte bereits die erste eingesetzte Generation von 
ARM Prozessoren eine MMU, wenngleich extern. Und so wurde die 
User/System-Privilegientrennung von Anfang an auch verwendet. Die 
Eignung von ARM für Embedded Systems war nicht Ziel der Entwicklung 
sondern ergab sich ursprünglich als Nebeneffekt. Und so steckt das halt 
auch im ARM7 Core drin, ohne dass es im Kontext monolithischer 
Microcontroller-Programme sonderlich viel bringt.

> Ein Kollege, mit anderen ARM, ARM9, beschäftigt, sagte mir dazu, der
> USER-Mode sei schon sinnvoll, verhindere eine Menge Unfug und
> unstrukturierte Programmierung.

Könnte daran liegen, dass viele ARM9 Systeme über eine MMU verfügen und 
nicht selten echte Betriebssysteme wie Linux eingesetzt werden, die eine 
MMU auch erforderlich machen.

ARM7 mit MMU ist hingegen eher selten und die verwendeten Programme sind 
meist von monolithischem Charakter. Entsprechen also weniger einem PC 
mit separatem Betriebssystem und all seinen darauf laufenden 
unabhängigen Programmen als vielmehr einem einzelnen PC-Programm, 
möglicherweise mit RTOS-Library vgl. manchen älteren reinen 
Userspace-Threadings in Unix.

Apropos unstrukturierter Code: Es stimmt schon, dass man bei 
Privilegientrennung dazu gezwungen wird, Funktionen (SWIs) für 
Interrupt-Steuerung zu verwenden. Nichts und niemand ausser dem inneren 
Schweinehund hindert einen jedoch daran, auch ohne Privilegientrennung 
strukturiert zu programmieren.

Mit dieser gleichen Logik sollte man lieber nicht in C programmieren. Es 
gibt weiteraus besser definierte und kontrollierende Programmiersprachen 
(Ada beispielsweise). Da man jedoch um C in der Praxis meist nicht herum 
kommt, hat man ohne eine gewisse Disziplin hinsichtlich 
Programmiertechnik und Programmstrukturierung ohnehin schnell verloren.

Um zu einem konkreten Beispiel zu kommen: Was Interrupt-Steuerung 
angeht, kommt man mit C++ weitaus weiter. Darin sieht eine vor Interrupt 
geschützte Funktion nämlich so aus:

1

void

2

UARTbase::put(int c)

3

{

4

    OS::Critical cs;

5

    if (txidle) {

6

        uart->thr = c;

7

        txidle = false;

8

    } else {

9

        tx.put(c);

10

    }

11

}

Die ganze Interrupt-Steuerung steckt hier in Konstruktur (save+disable) 
und Destruktor (restore) vom Objekt "cs". Insbesondere kann man so nicht 
versehentlich vergessen, die Interrupts wieder einzuschalten (per return 
irgendwo zwischendrin) weil der Compiler selber dafür sorgt, dass der 
Destruktor garantiert und an der richtigen Stelle aufgerufen wird.

Ob man in der Implementierung von OS::Critical die Interrupt-Flags 
direkt steuert oder auf SWIs abstützt, ist dann gleichwertig, das eine 
nicht sicherer als das andere. Und weil das Zeug ggf. nur aus 
inline-Funktionen besteht, ist es auch effizient.