Linux på emulerad x86 i javascript

[sodjan]

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

Nja, det är inget konstigt med det alls. I princip alla utvecklingsmiljöer för AVR, PIC
och liknande är korskompilatorer. Ingen av dessa miljöer körs på målmiljön direkt.
Notera att man med "cross-compiler" alltid menar i *en* riktning, inte fram
och tillbaka mellan två arkitekturer.

[Nerre]

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.

Lex, Yacc, flex och bison är väl rätt flitigt använda idag och de flesta av dem har rätt många år på nacken.

Fast de behövs ju bara om man skriver ett nytt språk, ska man porta ett språk till en ny arkitektur så utgår man ju från en befintlig kompilator.

För gcc finns det tydligen nåt som heter "machine descriptions" som man använder för detta.

[hanzibal]

@sodjan: Aha, jag har nog missförstått bregeppet. Jag tänkte på när låter en kompilator kompilera sig själv för den maskin den är gjord att sedan kompilera kod för.

Jag skrev en gång en slags mellankodskompilator i C under Linux för att översätta "GNU-assembler" (.s) till 32bit Turbo assembler (.asm). I Linux fick denna översättare sedan översätta sig själv till TASM som jag sedan assemblerade och länkade till ett körbart program i DOS för DOS. Nu kunde jag använda programmet för att göra översättningen direkt i DOS och sedan länka med en 32bit länkare med stub-kod (DOS extender) för protected mode (ungefär som DOS/4G som Id Software använde för att köra spelet Doom under DOS). Anledningen till allt detta besvär var att GCC inte hade någon protected mode länkade vid den tiden, d.v.s. ingen DOS extender. Poängen var den att jag sedan kunde skriva program i C och köra dem i 32bit protected mode under DOS. Detta genom att kompilera C-koden med DOS-versionen av GCC till .s och sedan översätta denna till .asm. Därefter assemblera med TASM och slutligen länka till en .EXE med inbyggd DOS extender. Allt detta meck låg i makefilen så det var inget man märkte utan det bara trillade ut en .EXE.

@Nerre: "För gcc finns det tydligen nåt som heter "machine descriptions" som man använder för detta." Aha, det visste jag inte, det förenklar ju en hel del även om det kanske inte är så lätt att författa dessa.

[Nerre]

Jag googlade lite på "porting libc" och "porting gcc" och hittade en massa intressant läsning. Men hade inte tid att plöja allt.

Vet inte om gcc är det vettigaste att börja med heller, gcc är tydligen väldigt komplex eftersom den dels är gjord för en massa olika språk OCH dessutom gör plattformsbaserat optimering ganska tidigt i kompileringen. Finns kanske andra kompilatorer som är bättre uppdelade.

[maDa]

Hah, jo. Folk gör helt otroliga saker i JS nuföritden. Vissa har gott om fritid helt enkelt

[sodjan]

> Jag tänkte på när låter en kompilator kompilera sig själv för den maskin den är gjord att sedan kompilera kod för.

Ja, det är väl så som alla nya versioner av en kompilator "byggs".
Hur skulle det annars gå till?
Visst, man skriver sannolikt inte en Cobol kompilator i Cobol, men
en C kompilator kan sannolikt mycket väl skrivas i C.

[hanzibal]

Nej, det finns nog inget annat sätt men tycker ändå att principen är rätt läcker. Det där om existentiella frågeställningar var lite överdirvet från min sida.

[sodjan]

En annan sak är korskompilatorer för datorer som inte ens finns.
Det är inte helt ovanligt vid utvecklingen av en ny arkitektur, även
om det kanske inte direkt dräller av nya arkitekturer idag. Men
tekniken är gammal och väl beprövad.

[blueint]

Vilken kompilator kompilerade den första kompilatorn?

[sodjan]

Den första kompilatorn skrevs i assembler.
Men det visste du säkert redan...

[stekern]

Vet inte om gcc är det vettigaste att börja med heller, gcc är tydligen väldigt komplex eftersom den dels är gjord för en massa olika språk OCH dessutom gör plattformsbaserat optimering ganska tidigt i kompileringen. Finns kanske andra kompilatorer som är bättre uppdelade.

LLVM är _mycket_ lättare att göra en backend port till, du kan utan någon som helst förkunskap få ihop en fungerande kompilator på ca 1-2 månader.

[hanzibal]

Den första kompilatorn skrevs i assembler.
Men det visste du säkert redan...

Vilken kompilator kompilerade assembleraren då?

[stekern]

Ingen, en kompilator producerar assemblerkod.

[hanzibal]

GCC gör ju det om man vill men oftast är det väl något slags mellanspråk som väl iofs ofta ser ut som assembler fast mer generell.

Här menade jag att assemblerararen (jmfr TASM) ju också är ett program som någon skrivit.

Första versionen i maskinkod, alltså ren binärkod där man bit-fiddlar ihop instruktionerna. När den funkar skriver man om den i assembler och låter den assemblera en förbättrad version av sig själv med fler finesser. När nya assembleraren är tillräckligt bra och skriver man en C-kompilator i denna assembler. När den funkar bra skriver man om den i C och låter den kompilera en förbättrad version av sig själv, osv, osv.

Så här rullar det på tills man uppnått Nirvana och då har man fått C#

[blueint]

Först var det jobbigt sedan åstadkom man nirvana med C, men se sedan gick det lite snett i C++, därfter var katastrofen slutgiltig med C#