Architektur Überblick

Kann sein, dass ich was vergesse, meine Notizen sind über viele verschiedene Systeme verteilt. Es ist auch nicht so, dass ich alles gleich aufschreibe, manchmal schreibe ich aber auch ganz schönen Quatsch. Ich denke wichtig ist vor Allem, dass ich weiß, wo ich mit dem Projekt hin will und wo ich Chancen sehe das in der Realität umzusetzen.

Es geht ja eigentlich um eine neue Hardware-Architektur, unter x86 will ich mich mit den dortigen Lösungsansätzen beschäftigen.

"Fahrplan": Java-Emulator -> x86 Mikrokernel -> HW-Design

Eingangs sollte ich erwähnen, dass die Architektur NICHT primär auf A: Performance, B: Speichereffizienz oder C: Kosteneffizienz ausgelegt ist. Ich vernachlässige hier den Semantischen Editor, Diagramme und andere Aspekte zur Entwicklung und konzentriere mich mehr auf das hardwarerelevante Design.


SW-Seite:

Operationen: jeweils ein Element der Flusskontrolle oder eines Ausdrucks.

Umgebung: Mit Umgebung meine ich hier nur deklarierte Variablen zur Zeit der Ausführung.

Deklaration: Bestimmte Operationen (OP_SEQUENCE) können Variablen deklarieren. Diese werden auf ihren Stack gespusht und stehen ab sofort als Umgebung zur Verfügung. Am Ende einer Operation wird der Stack mit setSize() auf den Ausgangszustand zurückgesetzt.

Funktionen: Man könnte sagen, jede Operation ist eigentlich ein Funktionsaufruf, was so nicht stimmt. In der Tat unterschieden sich Funktionen von anderem Code aber nur durch spezielle Anforderungen an die Umgebung des Aufrufs.

Variablen 1: Variablen haben eine "Version". Da jedes Stück Code quasi unabhängig von seinen "Eltern" ist, kann dieses von jedem Punkt aus aufgerufen werden. Die Variablenzugriffe stellen dabei Zugriffe auf ihre Umgebung dar und können ebenfalls auf weitere zurückliegende Versionen zugreifen (Stack).

Variablen 2: Alle Codes und Types (Klassen) werden wie Daten behandelt. Soll heissen, dass ein Prozess nur seine Variablen-Stacks verwaltet.

Abstrakter Code / Makro: da Funktionen auf ihre Umgebung zugreifen und Code wie Daten in Variablen gehalten wird, kann man elegant Makros schreiben, welche die selbe Aufgabe in mehreren Varianten bearbeiten können. Stichwort: habe keins, habe mich aber schon OFT über das Fehlen einer solchen Möglichkeit aufgeregt.

Strukturen: Klassen, Listen, Vektor-Arrays, Hashmaps, ... allgemein implementiert als Hashmaps ähnlich JSON-Objects mit Key-Value Definitionen. Im Emulator-Code habe ich häufig sowas: resolve(new AccessChain(new StackAccess(), new StructureAccess(), ...))

Identifier: Alle Variablen, Struktur-Properties, Threads, Prozesse, Programme, Hardware-Einheiten, ... haben ihren eigenen eindeutigen Identifier, mit dem auf sie zugegriffen werden kann. Diese setzen sich generell zusammen aus einem Name von Menschen gewählt und einem Zähler, neben anderen Abhängigkeiten (z.B. Thread welches Prozesses).

Hypervisor: vermutlich der interessanteste Teil. Besteht aus einem Scheduler, der Speicherverwaltung und Zugriffskontrolle. Der Scheduler arbitriert die Prozesse/Threads, popt den Callstack, pusht Variablen-Stacks (Deklaration) und pusht den Callstack pro untergeordneter Operation.

Subsysteme: APIs verschiedener Plattformen bereitstellen.
Treiber: normaler Code, erweiterte Berechtigungen: Port I/O, Interrupt, ...
Import: vorerst nur Java. Später alles, was sich irgendwie kompakt realisieren lässt (antlr/javacc)
Export: vorerst nur x86 wie eingangserwähnt zur Evaluierung von praktikablen Ansätzen.
(Thread-)Synchronization: Operationen sind schonmal atomar. Alles andere muss mit speziellen Deklarationen erfolgen. Auf mögliche Deadlocks wird hingewiesen.
Ausdrücke: haben einen eigenen Stack für Operanden/Ergebnisse. Ansonsten normale Ausführung (suspendable).

HW-Seite:

Hypervisor: nach dem Bootstrap-Code kommt der Hypervisor code. Dieser funktioniert mit festen call stacks (max 8 fach rekursion oder so) und festen speicheradressen.

Layout:
0 - 0x400 interrupt vector table
0x400 - 0x500 bios1
ab 0x500
fixed procedure jump table
procedureList (non-hypervised procedures, use fixed stack for executing hypervisor)
interrupt proxy list ()
0xA0000 - 0xC0000 vga
0xC0000 - 0x100000 bios2
ab 0x100000 bootstrap code
dann:
page directory
global descriptor table
taskstate segments (one per core)
fixed memory for hypervisor
process list

äh, ich schicke noch den export-code in java, noch nicht ausgereift...


Speicherverwaltung 1: Jeder Prozess hat seine eigenen Pages. Jede Page beinhaltet ausschließlich Objekte einer festen Größe (power of 2). Neue pages werden zum Prozess allokiert, wenn alle pages dieser Speicherklasse voll sind oder komprimiert und deallokiert, wenn die Auslastung von Pages unter einen bestimmten Schwellwert fällt. Hier kann man wunderbar alle Algorithmen parallel in HW laufen lassen.

Speicherverwaltung 2: Code, Daten und Management-Daten (hashtables, paging info) getrennt.

Persistenz: Soll allein durch Swapping von Pages realisiert werden. Sowas wie FAT kommt erst später.

Scheduling: Round Robin mit Priorität (Prozesse kommen nur dran, wenn alle Prozesse höherer Priorität schlafen). Threads analog zu Prozessen, jedoch erst, wenn der jeweilige Prozess ausgeführt wird.

Cache: Die neue Architektur geht ausschließlich über die Speicherverwaltung und hat keine Mehrzweckregister. Deshalb muss der Cache eine Schnelle Alternative zu Registern bieten. Eigentlich ist Cache ja nur teurer als RAM...

Multi-Core: Da der Datenfluss im Code statisch analysiert werden kann, können Programme massiv parallel und auf mehreren Cores laufen. Benötigt natürlich möglichst schnellen Austausch von Daten und Ereignissen zwischen den Cores.

Distributed: Ähnlich Punkt Multi-Core. Ein Programm kann dynamisch auf mehrere Hardware-Einheiten verteilt werden. Je nach Bandbreite und Latenz kann dies dynamisch angepasst werden. Stichwörter: Webanwendung, Cloud.

Kommunikationsprotokoll: Jedes Programm kann Ereignisse an andere Programme senden und auf Variablen (und damit auch Code) zugreifen (IPC). Die Kommunikation zwischen Hardware-Einheiten (Bus) und im LAN erfolgt oberhalb der Übertragungsschicht einem standardisierten Protokoll, welches identisch ist zum Protokoll der IPC. Jedes Gerät hat seinen eigenen eindeutigen Identifier.

Netzwerk: Zwischen Geräten der erwähnten Architektur gibt es ausschließlich die Kommunikation über IPC.


Also es gibt ca 1000 Dinge, die ich zuirgendeiner Zeit mal evaluiert und entschieden habe. Da ich diese nun für selbstverständlich halte könnte es unter Umständen schwer bis unmöglich sein meine Gedanken nachzuvollziehen. In diesem Fall bitte fragen.