nitro2k01 skrev:jag har väl nämnt den förut, men har du funderat på att utnyttja tekniken "cache-as-ram" för att slippa externt RAM-minne?

Vet inte vad det innebär. Finns sådant till x86 system? Numera så finns ju knappt system med mindre än 512MB att köpa ens. Det är verkligen "overkill" när RDOS kör på 4MB i minimal konfiguration.

Landet runt visade vår terminal i söndags (ca 30.00 in i inslaget):

http://svtplay.se/v/2340689/landet_runt/del_7_av_40?cb,a1364145,1,f,-1/pb,a1364142,1,f,-1/pl,v,,2340689/sb,p103509,1,f,-1

rdos skrev:

nitro2k01 skrev:jag har väl nämnt den förut, men har du funderat på att utnyttja tekniken "cache-as-ram" för att slippa externt RAM-minne?

Vet inte vad det innebär. Finns sådant till x86 system? Numera så finns ju knappt system med mindre än 512MB att köpa ens. Det är verkligen "overkill" när RDOS kör på 4MB i minimal konfiguration.

Han menar nog att eftersom det finns CPUer idag som mera än 4MB i L2-cache, så kan du köra RDOS helt utan RAM, och bara använda cachen. En ganska kul tanke, faktiskt.

SICS bedrev nåt forskningsprojekt om det för knappt 10 år sen.. COMA (Cache Only Memory/Machine Architecture) tror jag de kallade det. Borde kunna finnas lite läsvärda rapporter från det projektet. Tror det baserade det på MC88100 om jag inte missuppfattat nåt.

Kvasir skrev:

rdos skrev:

nitro2k01 skrev:jag har väl nämnt den förut, men har du funderat på att utnyttja tekniken "cache-as-ram" för att slippa externt RAM-minne?

Vet inte vad det innebär. Finns sådant till x86 system? Numera så finns ju knappt system med mindre än 512MB att köpa ens. Det är verkligen "overkill" när RDOS kör på 4MB i minimal konfiguration.

Han menar nog att eftersom det finns CPUer idag som mera än 4MB i L2-cache, så kan du köra RDOS helt utan RAM, och bara använda cachen. En ganska kul tanke, faktiskt.

DET är en cool tanke!

Nu fungerar det mesta kring SMP (Symetrisk MultiProcessing). Körde ett avancerat testprogram under natten på min MiniPC med Hyperthreading (2 logiska kärnor), och det fungerade. Har kört samma testprogram med 3 riktiga kärnor i en AMD Athlonx2, där det oxå fungerar (dock behöver timerfunktionen uppdateras för SMP).

Nu skulle jag bara behöva en dator med en i5 eller i7, eller helst flera stycken på samma moderkort.

För ett antal år sedan (t.ex. då jag först skrev den här tråden) så trodde jag att jag helt skulle bojkotta AMDs dåligt designade "long mode" (eller 64-bitars mode). Fast numera finns det faktiskt stöd för att köra 64-bitars kod i RDOS.

Att det fungerar rätt så bra att mixa 64-bit med 32-bit och segmentering beror på att AMD och Intel utelämnat ett antal viktiga punkter i sina specifikationer. Det är t.ex. så att det går att göra far-calls både ifrån 64-bit till 32-bit och tvärtom. Det går att använda 32-bitars segmenterad kod för att hantera 64-bitars applikationer på ett relativt smärtfritt sätt som har likartad prestanda som 64-bitars, och med betydligt bättre minnesskydd.

Visserligen så behöver 64-bitars applikationer (och överhuvudtaget själva long mode), 64-bitars interrupt och exception-hanterare, men det fungerar relativt bra att ha parallella versioner som anropar samma basfunktioner (som kör med segmentering).

Jag tror dessutom jag använt en helt unik design i mitt 64-bitars koncept. Istället för att låta 32-bitars applikationer köra via 64-bitar, som skulle kräva användning av syscall instruktion och samma soppa som i Linux/Windows, så kör jag 32-bitars applikationer i vanligt 32-bitars "protected mode", och 64-bitars applikationer i 64-bitars "long mode". Att switcha mellan dessa tar inte längre tid än att byta process och tömma alla page-cachar.

Som miljö för 64-bitar har jag övergett OpenWatcom. Istället har jag åter börjat titta på GCC, binutils och newlib. Till skillnad från förra gången så har jag nu fått patcharna till GCC accepterade. Målet är att 64-bitars miljön ska bli 100% POSIX-kompatibel, med effektiva fork och signal-implementationer. Detta är möjligt då denna miljö inte behöver stödja DOS/Windows koncept för applikationer, utan kan göras helt från början. Lösningen bör bli betyligt mer effektiv än Cygwin.

På den kommersiella sidan så finns i dagsläget ca 450 installationer av RDOS, och fler är på väg.

Fascinerande läsning. tummen upp ifrån mig.

Jag diggar verkligen folk som har så djup kunskap att dom kan skriva sitt eget OS.
Önskar att jag själv hade drivkraften att åstadkomma nått liknande.

Med microsoftgyttjan som startpunkt så kan det bara bli bättre och har man dessutom specifika behov så är det bara att sätta igång..

Ett tips: L4 microkernel family

plåtmonster skrev:Med microsoftgyttjan som startpunkt så kan det bara bli bättre och har man dessutom specifika behov så är det bara att sätta igång..

Ett tips: L4 microkernel family

Jo, microkernels är intressanta. Till att börja med så kommer 64-bit att använda befintliga 32-bit drivrutiner, som då har segmenteringsskydd. Jag kommer inte att tillåta "flat" i kärnan, varken 32-bit eller 64-bit (med undantag för det som krävs för att supporta exceptions och syscall-interfacet).

I ett senare läge så funderar jag på att implementera ett 64-bit microkernel-liknande interface som kör drivrutiner som "applikationer" (user mode), och kommunicerar med IPC. Framförallt så tänker jag mig att filsystem och sådant skulle kunna använda ett sådant interface.

matgar skrev:Fascinerande läsning. tummen upp ifrån mig.

Jag diggar verkligen folk som har så djup kunskap att dom kan skriva sitt eget OS.
Önskar att jag själv hade drivkraften att åstadkomma nått liknande.

Nja, den främsta meriten är nog extrem envishet. Dessutom bör man inte vara en sådan som ideligen början om från början när någon design ändras, för då kommer man aldrig förbi initialskedet.

Jag har ju hållit på från och till sedan 1988. Visserligen är relativt mycket omskrivet på senare tid, men en del designidéer håller fortfarande.

Det är ju oxå en fördel om man kan läsa kod man skrev för 5-10 år sedan. Annars blir det besvärligt.

Min tanke är att ett systemupplägg med mikrokärna (microkernel) hadde svårt att fungera på de x86-PC maskiner eller för den delen de vanliga Sparc baserade maskinerna som helt enkelt saknade snabbt minne i tillräcklig mängd för att det skulle fungera i praktiken och det blev monolitisk kärna (SunOS, Linux, FreeBSD osv).

Men de processorer som finns nu och som har cache direkt i samma CPU chip i form av L1-L2-L3 med MByte i kapacitet gör att ett mikrokärne upplägg borde kunna utformas på ett sätt som även har rejäl prestanda.

Finessen är att man då kan skydda mot problem i drivrutiner, filsystem osv. I tillägg så kan man då byta system under drift! (utgår jag ifrån)

SICS hade för en massa år sen nåt projekt som handlade om COMA (Cache Only Memory Architecture). Jag har nåt svagt minne av DDN - Data Diffusion Mechanism i det sammanhanget, men jag är alldeles för trött för att googla det ikväll.
Dessutom kanske vidare diskussioner i ämnet datorarkitektur lämpar sig bättre för en ny tråd.

Vad är Data Diffusion Mechanism för något?

Se tråden om datorarkitektur.

Jag tror knappast att en mikrokärna kan bli snabbare än en monolitisk kärna öht om allt som räknas är snabbhet. Att byta ring och page-tabeller kan aldrig bli något vidare snabbt, oavsett aritektur.

Fast om man å andra sidan vill ha något säkrare än en monolitisk kärna som använder "flat", och där minneskydd i praktiken är obefintliga, då kan det tänkas att en mikrokärna kan konkurrera med alternativ som segmentering och interpreterande språk.