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