Thema: Eigene CPU

[erik.vikinger]

Hallo,

Wie gesagt, ihr schreibt mir zu viel, um alles zu lesen.

Ich hätte erwartet das Du wenigstens den Beitrag liest den Du zitierst.

[.....]

Der war doch nun wirklich nicht mehr soooooooo lang.

Wenn du mit dem Defragmentieren anfängst, ist das Segment doch am Stück.

Nicht immer, das hängt von der Ursache des Defragmentierens ab. Falls ein Segment vergrößert werden soll aber nicht einfach wachsen kann oder falls ein neues Segment angelegt werden soll und es keinen ausreichenden Frei-Speicher in einem Stück gibt dann muss das Segment sofort (sonst würde das System blockiert) in mehreren Teilen entstehen. Dazu benötige ich aber eben auch sofort einen neuen Bereich im linearen Speicher (der gerade beim zweiten Fall) nicht unbedingt im 1:1-Bereich liegt. Daher ist mir die Idee mit der virtuellen "Swap-Out-Arrea" gekommen. Wo die liegt ist erst mal egal und komplett 4 GByte RAM geht auf der 32Bit-Plattform eh nicht.

Warum es nicht einfach dort lassen, wo es ist, während Paging aktiv ist?

Das wird wohl nur selten gehen. Das geht IMHO nur wenn ich nicht-fragmentierte Segmente nur verschieben möchte (wegen memory-compaction bzw. free-space-consolidation). Obwohl auch dazu der Ziel-Bereich im linearen Speicher ja bereits frei sein muss oder nur durch das betroffene Segment selber belegt sein darf und ich daher auch das virtuelle verschieben vor dem physischen Verschieben durchführen kann.

Oder wenn dir der Quellbereich nciht gefällt, nimmst du eben den Zielbereich her

Das dürfte schon eher was bringen. Wenn ich ein Segment vergrößern muss und es nicht wachsen kann (weil was anderes im Weg liegt) dann kann ich auch gleich einen neuen Bereich für das ganze Segment suchen und dort das Segment gleich virtuell hin verlegen. Der neue Segmen-Teil wird gleich 1:1 genommen (trotz Paging) und der alte Teil wird erst mal über das Paging eingeblendet. Nach dem der Paging-Teil in die neue Heimat umgezogen ist kann dann das Paging-Enable-Flag im Segment-Descriptor einfach aus geschaltet werden.

den brauchst du genauso in zusammenhängender Form, wenn du Paging irgendwann wieder ausschalten willst.

Ja, es ist mein Ziel das nach dem defragmentieren jedes Segment an einem Stück im physischen Speicher liegt. Sonst werde ich ja das böse Paging nicht los.

Wenn es keinen passenden Bereich gibt, hast du doch sowieso verloren, oder?

Ja, genau das ist mein Problem.
Ich könnte ja theoretisch den linearen Speicher doppelt benutzen, es wäre durchaus möglich das an der selben linearen Stelle 2 verschiedene Segmente liegen, einmal mit und einmal ohne Paging, die dann auf verschiedene physische Speicher-Bereiche verweisen. Aber wie gesagt, das wäre selbst für meine Verhältnisse ziemlich verrückt (und dann wohl doch der Weg in die Hölle).

Auch hier wollte jemand einen ähnlichen Weg gehen http://www.halfbakery.com/idea/Hardware_20concurrent_20memory-compaction_20assist, zusätzliche Aufmerksamkeit verdienen die Kommentare.
Zumindest bin ich nicht der einzigste auf diesem Erdenrund der solche Gedanken hat.


Grüße
Erik

[chris12]

so da ihr hier viel diskutiert habt, wollte ich mal anfragen, ob schon was bei rausgekommen ist, also ob ihr schon ein konzept habt, oder ob ihr euch immernoch mit den ganzen einzelhein rumschlagen müsst?

ich hab schon was zu stande gebracht: ist zwar nur 8 bit aber immerhin

auf dem bild hat die CPU ein byte (0Fh) aus speicherstelle 04h ausgelesen, und es dann auf dem Outport ausgegeben

so sieht die cpu in diesem zustand aus

[erik.vikinger]

Hallo,

so da ihr hier viel diskutiert habt, wollte ich mal anfragen, ob schon was bei rausgekommen ist, also ob ihr schon ein konzept habt, oder ob ihr euch immernoch mit den ganzen einzelhein rumschlagen müsst?

Wir haben vor allem viel über Speicher-Defragmentierung zur Laufzeit diskutiert. Dieses Konzept ist jetzt etwas klarer in meinem Kopf, aber es sind noch ein paar Fragen offen.
Ansonsten grüble ich noch über viele Detailprobleme. Vor allem mein Assembler geht derzeit nicht so gut vorwärts.

ich hab schon was zu stande gebracht:

Na das ist doch schon was!
Bis ich mal so weit bin wird sicher noch einiges an Zeit vergehen.

so sieht die cpu in diesem zustand aus
[Bild]

Aha, ich bin, äh, verwirrt.
Mit welchem Programm ist das erstellt?


Grüße
Erik

[chris12]

das programm nennt sich logisim http://ozark.hendrix.edu/~burch/logisim/
damit kann man diese schönen bildchen erstellen und auch gleich simulieren, ob das auch funktioniert

[MasterLee]

Ich hatte mir das mit der Speicherbereinigung mal wie folgt vorgestellt.
Der Speicher ist in Chunks aufgeteilt. Die MMU kann über denn Typ oder einen length Parameter ermitteln wie lang jeder Chunk ist.
Nun gibt es eine Reihe von Register die alle Adressen im Speicher enthalten.

Register	Beschreibung
pFree	Anfang des freien Bereichs
pCurrent	Anfang aktueller Chunk
pNext	Anfang nächster Chunk
Typ	Typ aktueller Chunk
Size	Länge aktueller Chunk
pRead	Leseadresse
pWrite	Schreibadresse

Am Anfang stehen alle Register auf Null
Nun wird wie folgt vorgegangen

• wenn pCurrent==pNext:
• wenn pCurrent>=pFree:
• pFree auf pWrite setzen
• pCurrent auf 0 setzen
• pNext auf 0 setzen
• pRead auf 0 setzen
• pWrite auf 0 setzen
• zum Anfang zurück
• wenn pCurrent<pFree:
• Typ von Chunk an pCurrent ermitteln und in Typ speichern
• Länge von Chunk an pCurrent ermitteln und in Size speichern
• pNext um Size erhöhen
• wenn pRead==pWrite oder Typ==Frei:
• pCurrent auf pNext setzen
• pRead auf pNext setzen
• pWrite um Size erhöhen
• zum Anfang zurück
• wenn pCurrent!=pNext:
• Aus Speicheran Postion pRead und in pWrite schreiben
• pRead um 1 erhöhen
• pWrite um 1 erhöhen
• wenn pRead==pNext:
• pCurrent auf pNext setzen
• zum Anfang zurück

Wenn ich jetzt Daten aus dem Speicher brauche muss ich denn Chunk ermitteln prüfen ob der Chunk pCurrent ist wenn ja muss ich die Adresse falls sie unter pRead liegt die Differenz zwischen pRead und pWrite verringeren.
Die Daten Chunks können über einen RADIX-Tree gefunden werden.
Der Die Zeiger im Tree müssen natürlich aktualisiert werden wenn ein Chunk bewegt wird.

Das zu implementieren wird nicht so leicht ;(

[erik.vikinger]

Hallo,

das programm nennt sich logisim http://ozark.hendrix.edu/~burch/logisim/ damit kann man diese schönen bildchen erstellen und auch gleich simulieren, ob das auch funktioniert

Danke, nur leider kann es wohl keine VHDL/Verilog-Komponenten einbinden. Eine große CPU nur durch gezeichnete Gatter zu bauen finde ich zu anstrengend.

Ich hatte mir das mit der Speicherbereinigung mal wie folgt vorgestellt.  .......

Ich bin mir zwar nicht sicher ob ich verstanden hab was Du meinst aber es klingt nach Paging mit variablen Page-Größen.
Mein Ziel ist es durch Segmentierung auf Paging (meistens) verzichten zu können um damit Performance und Sicherheit zu gewinnen. Paging will ich nur dann anschalten wenn ich damit irgendwelche Speicher-Magie, wie defragmentieren u.ä., machen muss.

Das zu implementieren wird nicht so leicht ;(

Das dürfte auch ziemlich langsam werden, aber ich lass mich da auch gerne vom Gegenteil überzeugen.
Die Pages in einer Art Baum zu verwalten dürfte zu sehr vielen Baum-Ebenen führen. Mehr als 4 oder 5 Ebenen (und entsprechend viele Speicherzugriffe) sind deutlich zu ineffizient, schließlich soll damit ja RAM verwaltet werden. Vielleicht kann da die flexible Page-Größe etwas retten aber ich vermute das Dein Konzept bei normalen User-Space-Programmen auf mindestens 10 Baum-Ebenen kommt und wenn der Baum unausgeglichen wird (weil Du z.B. immer an einer Stelle neue Pages anfügst) dann werden es sicher deutlich mehr Ebenen. So ein Baum dürfte wohl auch mehr Speicher beanspruchen als klassische Page-Directorys, und bestimmt auch mehr Verwaltungsaufwand im OS-Kernel.
Für einen brauchbaren/schnellen TLB dürfen die Pages auch nur 2er-Potenzen als Größe haben. Oder sind Deine 7 Register als eine Art TLB zu verstehen? Wenn ja dann müssten die mehrmals vorhanden sein.
Beliebige 2er-Potenzen als Page-Größen (auf der 32Bit-Plattform von 4 kByte bis 128 MByte, eventuell auch nur jede zweite 2er-Potenz von 4 kByte bis 64 MByte um den TLB-L2-Cache möglichst einfach zu halten) möchte ich auch verwirklichen und dabei trotzdem die klassische Page-Directory-Struktur verwenden, ist auch kein Problem.

Falls ich Dich total missverstanden habe dann versuche es bitte noch mal genauer zu erklären.


Grüße
Erik

[chris12]

dann nimm doch http://inst.eecs.berkeley.edu/~cs61c/sp06/projs/04/logisim-ucb-2.jar da kann man "Software Gates" benutzen, die kann man in c coden, man braucht nur gcc auf dem computer installiert haben. als template kannst du http://inst.eecs.berkeley.edu/~cs61c/sp06/projs/04/template.c nemen

[erik.vikinger]

Hallo,

dann nimm doch http://inst.eecs.berkeley.edu/~cs61c/sp06/projs/04/logisim-ucb-2.jar da kann man "Software Gates" benutzen, die kann man in c coden

Also in einer "normalen" sequenziellen Programmiersprache kann man IMHO keine parallele Logik beschreiben. Für ein paar Kleinigkeiten wird sowas sicher schon mal gehen, aber für ein richtiges Logik-Design, das man auch in einem FPGA (oder gar in einem ASIC) laufen lassen will, muss man dann doch die passenden Werkzeuge benutzen.

Der Einstieg in VHDL, oder auch Verilog, ist gar nicht so extrem schwer und passende SW mit richtigem Simulator gibt es bei den FPGA-Herstellen gratis (wenn man bereit ist ein paar GBytes zu downloaden).


Grüße
Erik

[chris12]

So jetzt möchte ich mich mal wieder melden und das thema aus der versenkung holen.
Ich hab ein wenig weiter gearbeitet und dabei sind gleich 3 cpu raus gekommen.
die drei cpu bauen alle auf einem ähnlichem ISA. der einzige unterschied zwischen allen ist, dass die erste, die 1408, eine 8bit CPU ist, die zweite, 1416, eine 16bit und die letzte eine 32bit cpu ist (ratet wie ihre bezeichnung ist )
Zu allen dreien gibt es nur EINEN assembler! sie alle haben eine identischen syntax und so sind nur die ausgespuckten bitweiten unterschiedlich.
zum aufwand: der dataparser war am komplexesten, dafür aber auch am kleinsten.
anzahl der dateien: 9
 parser.cs (parst mathematische ausdrücke; 326 Zeilen)
 1408.cs (generiert code für die 1408; 487)
 1416.cs (513)
 1432.cs (511)
 bin code.cs (sollte binärcode erstellen und in eine datei schreiben, unfertig; 17)
 emu code.cs (erstellt ein emulator ram image, es gibt einen 140A emu, der teilkompatibel zur 1408 ist; 19)
 logisim code.cs (erstellt code für logisim, der dann einfach in ein ram modul gelesen werden kann; 19)
 preprocessor.cs (der preprozessor, auf den ich besonders stolz bin, er kann macros definieren, konstanten, definitions abfragen machen, nachrichten, warnungen und errors ausgeben, die der benutzer definiert und andere dateien einbinden; 317)
 Program.cs (und schließlich die hauptdatei, sie enthält alles übrige, globale variablen, userinterface und den dataparser, 514)
gesamtzahl der zeilen: alles in allem nur 2723 zeilen

und damit ihr auch seht, wie denn der qellcode dann aussieht hier noch ein kleines beispiel

Code: [Auswählen]

%ifndef 1416
%error "Runs only on the 1416! simply Define the key '1416'."
%endif
%ifdef 1416
%warning "Make sure you assemble for the 1416!"
%define $zero r15
%define si r14
%define outr r13
%define $one r12
ld outr, 0x8000
ld $zero, 0
ld $one, 1

ld si, string
l:
mov r0, outr
sm si, $+2
lm r1, 0
cmp r1, $zero
je end
add r0, r1
out r0
out $zero
add si, $one
j l
end:
hlt

string: db "Hallo Welt!", 0
%endifdas der code gibt auf der 1416 "Hallo Welt!" aus, wenn der bildschirm sachgerecht an den outport angeschlossen ist.
achja zum hinweis:
ld -> LoaD nach(reg), was(konst)
lm -> LoadMemory nach(reg), von(konst)
sm -> StoreMemory von(reg), nach(konst)
out -> Output von(reg) auf dem 16bit outport
j -> vgl. jmp

[Programm Noob]

Moin

Die wievielte CPU ist das jetzt ? 6te?

Hast du dir schonmal gedanken über eiene komplett eigene Plattform gemacht? also Paging Interrupts und so weiter? Wäre mal interessant zu hören, wie du so etwas lösen würdest.

PNoob

[chris12]

das mit der sechsten CPU, dürfte hinhauen. leider funktionieren nur die letzten 3 nach meiner Zufriedenheit ^^
Das mit der eigenen Plattform, ist gar keine so verkehrte Idee, Buscontroller, Interruptcontroller, etc. könnte man ja mit dem bestand aufbauen, aber ob da Logisim noch mit macht? ^^
naja, ich werd mal sehen was ich machen werde, nen Buscontroller bräuchte ich eh.
leider muss sehr viel Code bei der Laufzeit verändert werden und ob das eine so gute Grundlage ist, weiß ich nicht. Aber man könnte ja eine CPU auf einer CPU errichten, des dürfte einige Probleme lösen, aber ob das ganze dann noch hinhaut. Naja ich werd mal sehen was die Zeit bringt.
bis dahin
mfg

[Programm Noob]

Aber denk dir bitte nicht so was verrücktes wie Segmentierung aus. bleib beim Flat Memory Modell. Ich hab vorhin mich wieder mit dem x86 Real Mode auseinandergesetzt. Grausam.

PNoob

[chris12]

mal sehen, was man mit 16bit alles machen kann ^^

[Programm Noob]

warum denn 16? ich dachte du hast ne 32 Bit CPU am laufen. nimm doch die oder will die nicht so wie sie soll?

PNoob

[chris12]

die 16bit cpu ist ganz einfach die, mit der ich am liebsten arbeite. bisher war sie, die am flüssigsten ausgeführt wurde, kann sich aber auch geändert haben. leider ist sie auch die, die am neusten ist, an ihr habe ich immer wieder kleine updates durchgeführt, die bei den anderen fehlen.
zu der 32 bit cpu: sie kann leider der ram nur mit einem 24 bit adressbus ansprechen, da logisim meint: "Neh du brauchst nicht mehr als 16.777.215 32bit zellen speicher ...."

[XanClic]

Aber denk dir bitte nicht so was verrücktes wie Segmentierung aus. bleib beim Flat Memory Modell. Ich hab vorhin mich wieder mit dem x86 Real Mode auseinandergesetzt. Grausam.

Hm? Erstens würde dir Erik da was husten, auch wenn der Realmode nicht unbedingt viel mit der ihm vorschwebenden Segmentierung (die wohl eher dem Protected Mode entspricht) zu tun hat.
Zweitens: Was ist denn genau das Schlimme an der RM-Segmentierung? Man kann lustige Sachen damit machen...

[kevin]

Mit PM-Segmentierung kann man aber noch viel lustigere Sachen machen.

[erik.vikinger]

Hallo,


@chris12:
Cool, ich bin beeindruckt!

gesamtzahl der zeilen: alles in allem nur 2723 zeilen

Das klingt nach ziemlich wenig, ich bin bereits bei über 6000 Zeilen und hab gerade mal die wichtigsten Befehle eingelesen, von Binärcode ist bei mir noch nichts zu sehen. Ich vermute aber mal das Du einen einfachen Single-Pass-Assembler gebaut hast. Bei meiner CPU-Architektur würde ich nicht mal mit nem Two-Pass-Assembler hinkommen.

Schon allein mein Literal-Parser hat über 1500 Zeilen, dafür kann er aber auch Klammern und Vorrangregeln (so wie C) und ist ziemlich einfach um neue Operatoren zu erweitern.
Und ich benutze C++ aber nur wenig von der STL so das ich viel von Hand mache was bei C# wohl mit der fest eingebauten Library zu erledigen ist.

Zur Simulation würde ich eher ModelSim empfehlen auch wenn damit riesige simulierte Speichermengen in einem noch viel größerem RAM-Verbrauch enden, um einen 4MBit-SRAM zu simulieren hat das ModelSim fast 500MB Speicher gefressen (aber da gibt es Möglichkeiten und Wege das zu minimieren). Der entscheidende Punkt ist aber das Du dafür VHDL (oder Verilog) lernen musst, überlege es Dir mal.

Aber denk dir bitte nicht so was verrücktes wie Segmentierung aus.

Was ist daran Bitte "verrückt"? Überlege doch erst mal was man mit richtiger dynamischer Segmentierung alles machen kann. Du kannst z.B. Speicher sharen und es ist völlig egal ob das 3 Byte oder 3 TByte sind (unabhängig ob ausgerichtet oder nicht), das macht im Kernel nicht einen CPU-Takt unterschied. Mit Segmentierung kannst Du den Speicher zur Laufzeit defragmentieren und noch ganz andere tolle Sachen anstellen. Und Du verlierst nicht bei jedem Speicherzugriff Performance, so wie beim Paging. Ließ Dir mal diesen Thread komplett durch.

Ich hab vorhin mich wieder mit dem x86 Real Mode auseinandergesetzt. Grausam.

Die Segmentierung im x86-Real-Mode ist auch grausam, da ist nichts dynamisches oder zumindest flexibles dran. Das ist einfach nur ein dämlicher Weg um einer 16Bit-CPU 20Bit-Adressen zu ermöglichen.

bleib beim Flat Memory Modell.

Und damit auf der dunklen Seite? Klar mit Flat-Memory kommt man leichter zum Ziel, aber ist nicht auch der Weg das Ziel?

Mit PM-Segmentierung kann man aber noch viel lustigere Sachen machen.

Das ist die richtige Einstellung! Willst Du nicht bei mir einsteigen? Ein Paar fähige Hände könnte ich gut gebrauchen und als Gegenleistung darfst Du mit einem signifikant erweiterten Horizont rechnen.


Grüße
Erik

[Programm Noob]

Entschuldigung, das ich deine Segmentierung nicht gut finde. Vielleicht ist deine Segmentierung besser. aber ich kenne sie nur ein wenig Theoretisch. Praktisch habe ich damit noch nichts angestellt. Ich kenne Nur die X86 RealMode Segmentierung und finde die Schei**.
Ich hoffe das deine Art der Segmentierung besser ist und wünsche dir viel Glück bei deiner CPU.
Ich bleibe mit meiner Architektur ganz brav beim FlatMemory  Modell, weil ich Flat Memory mit Paging persönlich schöner finde.

PNoob

[erik.vikinger]

Hallo,

Entschuldigung, das ich deine Segmentierung nicht gut finde.

Dafür brauchst Du Dich nicht zu entschuldigen, mit Meinungen hab ich kein Problem. Ich hab ein Problem damit das Du ein Konzept das Du nicht kennst als "verrückt" abstempelst ohne das rational zu begründen.

Ich kenne Nur die X86 RealMode Segmentierung

Und genau da ist das Problem.

und finde die Schei**.

Dem kann ich uneingeschränkt zustimmen.

weil ich Flat Memory mit Paging persönlich schöner finde.

Nie und nimmer würde ich Dir das ausreden, ich zeige Dir höchstens die belegbaren Nachteile Deiner Entscheidung.


Grüße
Erik