Hallo,
irgendwie gefällt mir dein Ansatz mit den erlaubten Bereichen und dem Co-Prozessor nicht. Das klingt alles so kompliziert.
Nun ok ich wollte eigentlich auch für die interruptbehandlung nen CO-prozessor einbauen(so ähnlich wie bei mips), soll ich den auch steichen?
Das hängt davon ab, wie kompliziert du dein Interruptsystem haben möchtest. Wenn du nicht jedem Interrupt eine eigene Leitung spendieren möchtest, brauchst du im Chipsatz eine Logik, die die ganzen Interruptquellen für die CPU verdaulich macht.
Eine MMU ist im einfachsten Fall ein SRAM.
Mhh der SRAM muss ja dann 1 MB groß sein oder? Ist das nicht etwas zu viel ?
Bei einer 32-Bit-Architektur sind das sogar 4 MB. Darum legt man diese Tabellen auf solchen CPUs in den normalen Arbeitsspeicher und führt ein mehrstufiges System (Page Directory, Page Tables) ein, damit sich verschiedene Tasks möglichst viel dieser Tabellen teilen können.
Wenn du für Hardware einen getrennten Adressraum vorsiehst, ist das recht einfach.
Naja hab eher an einen gemeinsamen Adressraum gedacht, wie wärs wenn ich den adressraum in 2 segmente unterteile(die größen der segmente sind immer gleich).
Das ist dasselbe in grün. Statt einer Steuerleitung, die zwischen Speicher und Hardware umschaltet, schaltet dann die oberste Adressleitung zwischen Segment 0 (Speicher) und Segment 1 (Hardware) um. Vorteil: Du kannst mit den normalen Befehlen deine Hardware erreichen. Nachteil: Jetzt muss jeder Befehl, der Speicher adressieren kann, den aktuellen CPU-Modus kennen...
Man könnte ja die pagegröße erhöhen(z.b von 4kb auf 16 kb) dann benötigt man ja weniger Sram da es weniger Pages gibt oder ?
Ja. Dann muss die MMU pro Task statt 4 MB nur noch 1 MB speichern - immernoch zu viel.
Naja wie wärs dann mit ein paar steuerbit in jedem SRAM eintrag ?
Das geht. Aus einer 32-Bit virtuellen Adresse machst du dann eine 30-Bit physische Adresse mit zwei Zugriffsbits. Das oberste Adressbit unterscheidet dann noch zwischen Speicher und Peripherie, fertig. Ergibt 512 MB maximalen RAM.
Gruß,
Svenska