Svenska ElektronikForumet

En kille som skrivit en x86-emulator med:

32 bit x86 compatible CPU
8259 Programmble Interrupt Controller
8254 Programmble Interrupt Timer
16450 UART
Real Time Clock.
IDE interface and hard disk

http://bellard.org/jslinux/

Går faktiskt att använda, här kompilerar jag hello.c och kör sedan programmet: Riktigt coolt tycker jag som länge funderat på att skriva en egen CPU i mjukvara och sedan porta Linux till den. Om det funkar så kunde man implementera den på CPLD/FPGA bara för glädjen över att ha gjort en egen maskin.

EDIT: Korrat stavfel.

Mjukvaru emulering och FPGA implementation är helt olika saker. Mao källkoden från det ena kan inte användas till det andra. I detta fall med mindre än att du skriver en Java interpretator för FPGA.. men då är det tillbaks på ruta #1 ändå.

Förstår att det blir knepigt att porta C# till WHDL
Menade mer att om min egen CPU-arkitektur fungerar ok så kunde man gå vidare och implementera den i FPGA/CPLD. Har iofs inte pysslat med FPGA men föreställer mig att man jobbar på lägre nivå och mer deklarativt genom att definiera allt från enkla grindar till sammansatta komplexa nät. Tror jag sett lite kod någonstans, verkar inte helt obegripligt och antar att det finns mycket färdiga klotsar man kan importera. Kanske helt fel.

Jag omtalade den häringa emulatorn i en annan tråd också men var ganska off-topic där så jag tog bort den och skrev denna tråd istället. Tycker den är skithäftig och verkar inte förekommit på forumet tidigare.

Finns ett antal färdiga soft-CPU till FPGA, tex http://en.wikipedia.org/wiki/Nios_II

FPGA är ju på sätt och vis riktig hårdvara men en FGPA-CPU lär gå väsentligen långsammare än motsvarande "riktig" CPU. Om man t.ex. jämför en ARM-implemention i FPGA med en riktig på samma klockfrekvens så har väl FPGA:n generellt sämre prestanda?

Ja, en CPU på en FPGA går långsammare.
Men om du vill ha en CPU så tar du inte en FPGA.
Lite som att en CPU går långsamt att simulera i minecraft.

Men nu var ju den här CPUn emulerad i JAVASCRIPT (inte java ens)? Den körs alltså i din webbläsare om jag inte fattat helt fel.

En FPGA lär väl gå snabbare än javascript i alla fall? :)

Det finns mycket som går att göra, även ganska meningslösa saker.

CPU i FPGA kan ju vara vettigt om man behöver ett stort antal I/O eller om det är snabba informationsflöden som behöver behandlas eller dyl, finns kapslar med 1932 pinnar.

sodjan skrev:Det finns mycket som går att göra, även ganska meningslösa saker.

Ja, som att skriva en CPU-emulator i javascript eller renovera gamla uråldriga datorer.

Eller bygga en dator av reläer.
http://elektronikforumet.com/forum/view ... =3&t=44171

Eller konstruera en egen CPU.
http://elektronikforumet.com/forum/view ... 7&p=900230
http://elektronikforumet.com/forum/view ... 1&p=547967

För att inte tala om att renovera gamla datorer som PDP8 och ABC80/800! :)

Finns även såna fascinerande saker som tcp/ip över ICMP.
http://thomer.com/icmptx/

Så det är väl inte så konstigt att nån kan tycka att det skulle vara roligt att ha konstruerat en egen CPU för att sem implementera den i FPGA och kunna bygga en komplett dator med den? :)

sodjan skrev:Det finns mycket som går att göra, även ganska meningslösa saker.

Tja, till skillnad från dig så kan jag inte allt redan och själva lärandet kan vara roligt i sig. Jag har lärt mig massor av att leka och göra meningslösa saker men det har såklart inte alltid lett till meningsfulla saker i slutändan Det skulle faktiskt inte förvåna mig ett dugg om inte de flesta stora innovationerna börjat som en "meningslös" lek.

Nerre skrev:Men nu var ju den här CPUn emulerad i JAVASCRIPT (inte java ens)? Den körs alltså i din webbläsare om jag inte fattat helt fel.

En FPGA lär väl gå snabbare än javascript i alla fall?

Ja såklart, det här med FPGA var en ren off-topic grej från mina sida. Tyvärr har jag en tendens att "skräpa ner" trådar...sorry.

EDIT: Här ytterligaren en emulator i javascript som kör Linux. Denna gång emuleras en Lattice ARM-processor:
http://www.ubercomp.com/jslm32/src/

sodjan skrev:Det finns mycket som går att göra, även ganska meningslösa saker.

Ja, t.ex. som att sitta på forum som en hök och göra meningslösa inlägg i trådar...

hanzibal skrev:Riktigt coolt tycker jag som länge funderat på att skriva en egen CPU i mjukvara och sedan porta Linux till den. Om det funkar så kunde man implementera den på CPLD/FPGA bara för glädjen över att ha gjort en egen maskin.

Är en kille som gjort en liknande (javascript) emulator till OpenRISC: http://www.simulationcorner.net/opencore/
Och det finns OpenRISC implementationer i verilog som det går att köra Linux på i en FPGA, så ditt scenario är ju helt klart möjligt.
Men det finns ju snabbare sätt att skapa sin emulator än att skriva den i javascript, qemu är väl förmodligen det mest naturliga (finns en qemu port för OpenRISC med).
Problemet om du vill skapa en helt ny arkitektur är att förutom att porta Linux till den måste du även porta toolchains (kompilator, assembler, c-lib etc)
till den. Allt detta är inte gjort i en handvändning (nästan ett större jobb än att göra själva processor implementationen).

Imponerande, kändes rapp också, jag var nog uppe i nästan 2 MIPS ett tag. Vad är fönstret till höger för?
Är OR1000 alltså din egen OR-baserade processorarkitektur?

Jo fy vilken massa jobb det blir. Jag har en föreställning om att man gör något i stil med detta:

Har för mig att gcc kan spotta ur sig ett slags generaliserad assembler-kod med filändelsen ".s". Nu var det länge sedan jag meckade med sånt här men vill minnas det som ett mellanspråk. Man skriver sin CPU och här kan man ju faktiskt isolera vissa delar och tillsvidare ta till lite högnivåkod. Efter att man skrivit sin CPU får man väl ta och skriva sig en "snurra" som baserat på mellankoden genererar motsvarande maskinkod för den egna CPUn. Redan här kan man ju provköra lite superenkla program, t.ex. loopa och summera tal, den typen av grejer.

Sedan tar man en Linux-kärna och lägger till och/eller modifierar de mest grundläggande hårdvarunära delarna; minnesstruktur, interruptkontroller, diskkontroller, realtidsklocka och allt annat som behövs för att skapa en dator. Den här biten är nog det som jag skulle ha mest besvär med tror jag.

Sedan kompilerar man kärnan och skapar en boot image komprimerad och hela middevitten. Så länge det hela emuleras i mjukvara så är ju t.ex. "bootloadern" en baggis. Sedan blir det väl att kompilera verktygen som krävs "på andra sidan" inkl. tool chain med gcc, länkare och så vidare. Sedan lägger man dessa saker i ett filsystem och bakar ihop med bootimagen. Bootar upp Linux, mounta filsystemet och test verktyg och kompliera resterande nyttoprogram där. Här är man framme i ett läge motsvarande dessa javascript-datorer vi sett tidigare i denna tråd.

I det här läget kan man ju "stop and smell the roses" - leka och ha skoj i sin Linux på sin egen dator, kompilera diverse program, daemons och konfigurera start-up sekvensen mm, allt för att förfina sin linux. Kanske skriva en NIC med brygga till hosten så att man får internet. Denna Linux-image blir den som kommer att köras senare också.

Sedan skall ju allt över på en FPGA och då skulle det verkligt knepiga börja, i alla fall för min del. En MMU t.ex. torde vara hyggligt enkel emulera i host-kod med hypercalls. Att plötsligt realisera den med "NAND-grindar" blir en helt annan 5:a...

Man kunde ju redan från början skriva emulatorn tämligen hårdvaru-realistisk. Detta på ett sätt som underlättar en portning till WHDL eller Verilog. T.ex. använda ganska "atomära" grundfunktioner och alltså inte fuska genom att packa in en massa avancerad logik i host-kod. Om man hittar en bra avgränsning melllan de atomära delarna så kan man ju ta dem en i taget och implementera om ännu mer maskinnära sätt, söndra och härska liksom. Låta den evolera fram successivt.

Slutligen portar man sin dator till FPGA eller kanske CPLD. Lätt som en plätt ju

Tror aldrig jag får tid till ett sånt här mastodontprojekt, kanske när jag blir pensinär. Fast vid det laget har jag troligen omvärderat hela tillvaron några gånger och lägger hellre tiden på att träffa barnbarnen, mata ankorna, resa och läsa böcker

Det går ju att korskompilera. Så när man väl byggt sin CPU så kan man skriva en GCC som kan korskompilera för den.

Jag tror att för kompilatorn räcker det faktiskt med att ha koll på instruktionsuppsättning, register- och minneshanteringen. Sen när man börjar portera libbar så måste man även ha koll på I/O-bitarna.

Jag har aldrig kollat källkoden för t.ex. libc, men jag skulle gissa att den är oerhört modulariserad så att det faktiskt är relativt få delar som behöver modifieras för en ny arkitektur.


Jag hittade en trevlig artikelserie för ett tag sen där man (om jag inte minns fel) gick igenom från början hur man skriver en kompilator. Den skrevs i Pascal har jag för mig. Let's build a compiler har jag för mig serien hette. Undrar om det var nån här som länkade till den...

http://compilers.iecc.com/crenshaw/

Den kompilatorn är dock "enstegs" om jag inte minns fel, d.v.s. varje rad i källkoden görs direkt om till assemblerinstruktioner.

De flesta moderna kompilatorer jobbar såvitt jag förstått med att först bygga upp ett "träd" av källkoden, det är sen det trädet som "optimeras" innan det i sin tur omvandlas till assembler. Fördelen med detta är att språkets syntax hanteras av parsern som bygger trädet, så för att anpassa för en ny processor så är det bara den den som bryter ner trädet till assembler som behöver ändras (och sen då eventuellt optimeringsbiten).

Sen kör de ju också flera steg (i alla fall för C). Först preprocessor som expanderar makron och inkluderar include-filer, sen parsas källkoden oftast en gång (eller fler) för analys innan det här trädet byggs. Man kan titta på hur ofta olika variabler används (för att lista ut vilka som bör ligga i register) och såna grejer. (Fast möjligen görs den analysen när trädet väl byggts, jag har som sagt var inte hundra koll.)

Med gcc så har jag för mig att man kan få den att spara väldigt många av mellanstegen. Jag har aldrig gjort det med stora program, men när jag lekte med avrgcc och blinkade lysdiod så tittade jag på det för att se hur kompilatorn optimerade (för att försöka få den kompilerade koden så lik min egen kod som möjligt).

En gång i tiden hade jag planer på att skriva en korskompilator till Z80 för att kunna skriva ett eget operativ till min Spectravideo 328:) Jag hade klurat ut ett rätt smart sätt att använda Z80:s alternate registers för task-swapping:) Jag hade en Super Expander till min SVI-328 så jag hade flera banker med minne också.

Korskompilering är rätt coolt och väcker nästan lite existerntiella frågor av typen hönan och ägget.

I skolan skrev jag en kompilator som var mycket lik C, genererade maskinkod (pregade in op-koder) och byggde egen länkare som lade ut text och data med rätt alignment. Det var till SUN SPARC på någon Unix. Preprocessorn tillförde ovärderlig hjälp, macron, includes, tom kommentarer har jag för mig - allt sånt som man kanske inte tänker på annars. Plötsligt blev språket riktigt användbart. Kompilatorn körde flera pass och klarade därför framåt-referenser. Den gjorde lexikalisk analys och byggde träd.

För själva parsern använde vi någon slags hjälpprogram där man definierade språket och fick sedan rätt mycket hjälp att generera kod för parsern. Detta gjordet det mycket enklare att skriva parsern.

SPARC körde med virtuella register i bankar om 32 st eller något ditåt. Man behövde inte veta hur många register som verkligen fanns men när de tog slut "swappade" CPUn automagiskt ut dem i RAM. Ganska smart även kompilatorn försökte optimera genom att hålla reda på vilka register som användes från tid till annan. RISC där alla instruktioner var 32 bitar långa, operanderna lade man ut separat.

Hela rasket skrevs i Simula