NeoISA
CPU
da ich mich sehr gerne mit hardware und entsprechender architektur beschätige, sollen hier die ideen und fortschritte dokumentiert werden. ich habe mich dazu entschlossen die unterschiedlichen entwicklungs abschnitte die eine gravierende änderung beinhalten auch von der entwicklung her zu trennen.
angefangen habe ich mit der basicVM, die die idee hinter dem befehlssatz anfangen soll zu verdeutlichen. spannend wird es dann mit der nächsten ausbaustufe ;)
basicVM
die basicVM die jetzt auf github zu finden ist, soll einen ersten eindruck geben, was eine stackmaschine die auch mit vectoren umgehen kann so alles zu leisten vermag. folgende features waren bei der entwicklung im vordergrung:
features:
- ssa stack basiert
- unified stack integer/float/bool und vector von diesen, bis zu einer maximalen länge von 1 cache line - 512bit
- es gibt einen arithmetik und einen call stack
- scratchpad für die inhalte des stack. stack hält die referenzen und zusatzinformationen wie z.b. den typ
- atomare 8bit befehle, die zu mehreren gebündelt werden können.
- konstanten füttern den stack mit parametern
- alle befehle die operanden benötigen, beziehen diese vom stack.
- alle befehle können mit vectoren als operanden umgehen, auch load, store, jump und call
- es gibt keine adressierungs modes. alle adressberechnungen sind selber durchzuführen.
- es gibt kein starres modell bezüglich vektor länge oder anzahl der parrallelen einheiten
nextVM
die nextVM ist in den meisten punkten identisch mit der basicVM, hat aber eine komplett überarbeitetes speicher- und programm-management.
features:
- ssa stack basiert
- unified stack integer/float/bool und vector von diesen, bis zu einer maximalen länge von 1 cache line - 512bit
- es gibt einen arithmetik und einen call programm-stack
- scratchpad für die inhalte des stack. stack hält die referenzen und zusatzinformationen wie z.b. den typ
- atomare 8bit befehle, die zu mehreren gebündelt werden können.
- konstanten füttern den stack mit parametern
- alle befehle die operanden benötigen, beziehen diese vom stack.
- alle befehle können mit vectoren als operanden umgehen, auch load, store, jump und call
- es gibt keine adressierungs modes. alle adressberechnungen sind selber durchzuführen.
- es gibt kein starres modell bezüglich vektor länge oder anzahl der parrallelen einheiten
- hauptspeicher wird immer über eine stack-memory-referenz angesprochen - stacksh
- direct scratchpad: es wird ein speicherblock vom scratchpad reserviert, und indirekt über das stackelement angesprochen
- direct memory: es wird ein speicherblock vom hauptspeicher über ein stackelement eingeblendet, und indirekt über das stackelement angesprochen
- indirekt memory: es wird ein speicherblock vom hauptspeicher über ein stackelement eingeblendet, über das scratchpad gecached, und indirekt über das stackelement angesprochen
- superblock programmausführung auf dem stack. superblock referenzen liegen auf dem stack und können wie dieser verwaltet und ausgeführt werden.
future features
- ssa stack cpu
- unified 1bit-512bit (2^0 to 2^9)
- jedes stack element hält zusatzdaten (typ, größe, zustandswerte)
- getrennte werte und call stacks
- in order
- extrem pipelined
- stash anstelle von cache - wird wohl eher stacksh. stack + scratchpad = stack(ca)sh(e)
- keine klassische mmu.
- linearer 64bit adressraum
- adressübersetzung an den übergängen zur peripherie - ram, io, ...
- software tlb
- atomare 8bit befehle, die auch gebündelt werden können, wenn es in die pipeline passt
- sicherheitsmodell auf speicherebene - mindestgröße ist cacheline (512bit)
- inter-prozess kommunikation mit sehr kleiner latenz
- implizites threading