ARM ausführbare Programme

[Teelöffel (Gast)]

Hallo,

Erst mal vor weg, ich wollte mal wissen ob meine Theoretischen Gedanken 
so richtig sind und ob es so Funktionieren kann.

Der ARM (z.B. ARM7 von Atmel) hat doch die Von-Neumann-Architektur? D.h. 
er kann Programmcode aus dem RAM ausführen?

So wenn ich jetzt ein Programme (Kernel) schreibe der den Code z.B. aus 
einer SD-Karte holt und diesen dann in den RAM lädt und ausführt. Ist 
dies erst mal so überhaupt möglich?

Wenn ja wie muss oder kann ich dann so ein Ausführbares Programm 
erstellen bzw. compilieren? Muss das dann eine HEX Datei sein oder eine 
BIN Datei oder kommt es "einfach" nur auf mein Kernel drauf an?

Ich hab mir das mit dem Ausführbaren Programm so vorgestellt. Der Kernel 
gibt alles bereit IO, LCD, SD, HDD, ... und das ausführende Programm 
kann dann ganz einfach wie gewohnt mit C Programmiert werden.
z.B.

#include <kernel/io.h>

int main(void)
{
   licht(ON);
}


Der ARM hat doch MMU was hast das dann für mich?

Ich würde mich freuen wenn ihr mir paar fragen beantworten könnt. Danke

[Martin T. (mthomas) (Moderator)]

Teelöffel wrote:
> Hallo,
>
> Erst mal vor weg, ich wollte mal wissen ob meine Theoretischen Gedanken
> so richtig sind und ob es so Funktionieren kann.
>
> Der ARM (z.B. ARM7 von Atmel) hat doch die Von-Neumann-Architektur? D.h.
> er kann Programmcode aus dem RAM ausführen?
Ja

> So wenn ich jetzt ein Programme (Kernel) schreibe der den Code z.B. aus
> einer SD-Karte holt und diesen dann in den RAM lädt und ausführt. Ist
> dies erst mal so überhaupt möglich?
Ist möglich.

> Wenn ja wie muss oder kann ich dann so ein Ausführbares Programm
> erstellen bzw. compilieren? Muss das dann eine HEX Datei sein oder eine
> BIN Datei oder kommt es "einfach" nur auf mein Kernel drauf an?
Auf den Kernel bzw. dessen "binary loader".

> Ich hab mir das mit dem Ausführbaren Programm so vorgestellt. Der Kernel
> gibt alles bereit IO, LCD, SD, HDD, ... und das ausführende Programm
> kann dann ganz einfach wie gewohnt mit C Programmiert werden.
> z.B.
>
> #include <kernel/io.h>
>
> int main(void)
> {
>    licht(ON);
> }
>
> Der ARM hat doch MMU was hast das dann für mich?
Was auch immer "Der ARM" sein soll. Nicht alle Controller mit einem 
ARM-core verfügen über eine MMU (vgl. z.B. Linux <-> uClinux)

[Robert Teufel (Gast)]

Also wenn der ARM eine MMU hat, dann hat eine keine Von Neumann 
Architektur mehr sondern Harvard, und andersrum. So eine Art Zwitter ist 
der Cortex M3. Allgemein gilt, ARM7 ist Von Neumann, ARM9 und darueber 
ist Harvard, da gibt es dann Caches (auch SRAM, aber eben etwas anders 
aufgebaut), von dort wirt dann Code ausgefuehrt. Der ARM7 hat im grossen 
und ganzen keine Caches. Es gibt noch sehr alte Cores, 720 und 740 mit 
Cache, doch das wuerde jetzt zu weit gehen.

Gruss, Robert

[Andreas K. (a-k)]

Robert Teufel wrote:

> Also wenn der ARM eine MMU hat, dann hat eine keine Von Neumann
> Architektur mehr sondern Harvard, und andersrum.

Das ist mir jetzt neu. Was hat die MMU mit Harvard zu tun???

Bislang kannte ich zwei alternative Kritierien für Harvard/von-Neumann:

(1) Inwieweit Code und Daten über gemeinsame Busse transportiert werden.

Dieses Kriterium mag für Entwickler von Prozessorkernen interessant sein 
und es kann die Leistung beeiflussen, dem Programmierer kann's aber egal 
sein, selbst Betriebssystemprogrammierer sind davon allenfalls in 
geringem Mass betroffen.

In diesem Sinn sind beispielsweise ARM7 und Intel386 vom von-Neumann 
Typ, ARM9 und Pentium vom Harvard Typ. Ob der ARM7 eine MMU hat ist 
dabei egal, denn an der Busstruktur ändert die überhaupt nichts.

Ob man einem 68000 eine externe MMU in den Adressbus einschleifte, oder 
ohne auskam, war eine Frage der Anwendung. Für Unix brauchte man die, 
für Amigas nicht. Mein Rechner hatte keine, der Rechner eines Freundes 
hatte sie, das selbstgestrickte Betriebssystem war aber identisch und 
hat sie nicht verwendet.

In den IBM 360ern war die MMU m.W. sogar Teil der Speichersystems, d.h. 
der Speicherkarten, nicht der CPU.

(2) Inwieweit Code und Daten getrennt oder gemeinsam adressiert werden.

Damit wird der Punkt betont, der damals als dieses Begriffe auftauchten 
den wesentlichen Unterschied ausmacht: Der Unterschied zwischen Code und 
Daten ist eine Frage der Interpretation durch das Programm und nicht 
bereits von der Architektur festgelegt.

Dieses Kriterium ist für die hier betrachtete Aufgabenstellung 
entscheidend, denn nur dann lässt sich ad hoc in den Datenadressraum 
geladene Code ausführen.

In der Fachliteratur wird, wohl aus einer gewissen Trägheit heraus, 
meistens 1=2 gleichgesetzt. Wird also angenommen, dass ein gemeinsamer 
Bus auch einen gemeinsamen Adressraum impliziert und umgekehrt. Was 
allerdings in der Praxis längt Unsinn ist.

[Andreas K. (a-k)]

PS: Andererseits lässt sich die hier betrachtete Aufgabenstellung auf 
beiden Typen implementieren, sofern der Harvard-Typ über beliebig oft 
schreibbaren Speicher für Code verfügt. Was allerdings bei voll 
integrierten Controllern mit getrennte Adressräumen üblicherweise nicht 
der Fall ist.

Übrigens entsprachen die ersten ARM Implementierungen strukturell 
ziemlich exakt ARM7, erst mit ARM9 trennten sich die Busse. Die daraus 
aufgebauten Acorn-Rechner hatten freilich von Anfang an eine MMU in 
einem separaten Baustein an Bord.