Taal met control-flow + direct geheugen-gebruik

[mbravenboer]

Ik ben wat aan het prutsen met een wat merkwaardige taal die directe geheugen toegang moet hebben en 'hogere' control-flow constructies zoals if, while, for. Om een beetje te spieken wat er handig zou kunnen zijn ben ik op zoek naar talen die dit bieden (en dus geen variabelen kennen, kom dus aub niet met inline assembly in C aan ).

Het gaat dus om een iets abstractere assembly vorm waar:
1. je dus minder jumps (geen) hoeft te gebruiken voor simpele loop of conditie constructies,
2. er geen variabelen zijn: je maakt direct gebruik van registers en geheugen,
3. er eventueel nog een expliciete notie van functies en procedures is.

Ik kon met Google niet echt veel vinden . Zoeken op control-flow, assembly gaat nog wel, maar while en for schiet niet zo op .

Iemand weleens van iets dergelijks gehoord?
Zo ja: linkje? Wat vond je ervan? Positieve punten, negatieve punten?
Zo nee: waarom bestaat dit eigenlijk niet?

[Verwijderd]

Toch assembly , als je tutorials een beetje door kijkt zie je die gast while lusjes en if then else dingen doen, neem aan dat ie 'n berg macro's heeft gemaakt ofzo!? is da ongeveer wat je zoekt?

http://spiff.tripnet.se/~iczelion/tutorials.html

[mbravenboer]

Yarvieh: Toch assembly

Tja ... .

als je tutorials een beetje door kijkt zie je die gast while lusjes en if then else dingen doen, neem aan dat ie 'n berg macro's heeft gemaakt ofzo!?

Hum ik heb vast een beetje zitten zoeken op de pagina waarnaar je verwijst, maar ik kon zo niet vinden waar je op doelt. Alles wat ik zag ging met gewone compares en jumps... Ik zal later nog ff beter rondkijken ( of uh... als je een direct linkje hebt...? )

Bedankt voor de link in ieder geval. Ik had al wat links verzameld, maar deze zat er nog niet bij .

is da ongeveer wat je zoekt?

Ik heb het dus nog niet gezien, maar waarschijnlijk zal het toch iets anders zijn dan ik bedoel: ik doel echt op een speciaal ontworpen taal en geen macro-constructies. Ook denk ik eerder aan C-- dan aan asm++ .

[Verwijderd]

Probeer eens te zoeken op HLL en asic.
De laatste is ook een taal, al ben ik het nooit tegengekomen anders dan dat Raid[SlaM] in beide een virus heeft geschreven. Dus het moet toch ook wel redelijk low level zijn.

[Bigs]

Ik meen me te herinneren dat MASM ook gewoon flow-control lussen in z'n code ondersteunt (en dan dus niet de kale Microsoft assembler, maar die andere).

[mbravenboer]

otaku-san: Probeer eens te zoeken op HLL en asic.

Bedankt voor de tips . Ik heb ff rond gekeken, maar helaas werd ik er niet veel wijzer van ... HLL schijnt de afkorting te zijn voor High-Level Language (zoals C). Voor zover ik asic begreep, ligt dat nog dichter bij de hardware dan assembly (dat schijnt mogelijk te zijn dus ).

over asic: Application-Specific Integrated Circuits, by Michael John Sebastian Smith. Since you are reading this web page, chances are you are a programmer concerned with speeding up your programs by using assembly language. But what do you do when even assembly language is not fast enough? Only one thing is faster than a well written assembly language program: dedicated hardware.

Heb ik verkeerd gezocht?

Bigs: Ik meen me te herinneren dat MASM ook gewoon flow-control lussen in z'n code ondersteunt (en dan dus niet de kale Microsoft assembler, maar die andere).

Ah, daar zal ik eens naar kijken . Maar deze ondersteunt dan uiteraard geen speciale syntax voor procedures en functies neem ik aan?

[Verwijderd]

Op donderdag 27 december 2001 13:04 schreef mbravenboer het volgende:

Hum ik heb vast een beetje zitten zoeken op de pagina waarnaar je verwijst, maar ik kon zo niet vinden waar je op doelt

voorbeeldje:
http://spiff.tripnet.se/~iczelion/tut14.html

code:

    .WHILE TRUE 
            invoke GetMessage, ADDR msg,NULL,0,0 
            .BREAK .IF (!eax) 
            invoke TranslateMessage, ADDR msg 
            invoke DispatchMessage, ADDR msg 
    .ENDW

[Verwijderd]

Niet dat je er veel aan in de zin van link, maar er wordt iets meer gezegd over HLLT Asic.

http://vil.nai.com/vil/virusSummary.asp?virus_k=98552

Beschrijving van Raid's Irok virus.

Raid post redelijk veel in newsgroups.

[mbravenboer]

Yarvieh postte ff een voorbeeldje

Ah, dat ziet er wel aardig uit... Het is wel duidelijk een asm++, maar toch interessant om ff te bekijken .

[.oisyn]

waarvoor heb je het eigenlijk nodig?

^{assembler wannabe}

[mbravenboer]

OiSyN: waarvoor heb je het eigenlijk nodig?

Ik ben een compiler aan het schrijven. Op zich is de taal en het resultaat niet zo heel erg interessant, maar de opzet wel: de compiler is opgebouwd uit een serie van intermediate representations (of eigenlijk een klein netwerk). Het is de bedoeling dat front-ends (taal, parser, type-checker) op een willekeurige ir kunnen instappen en dat back-ends (ir, instructie selectie, asm) op elk moment uit kunnen stappen. Voordeel: optimalisatie componenten zijn voor alle talen herbruikbaar en kunnen op verschillende lagen in de compiler werken en worden toegevoegd.

Dit lukt allemaal uitstekend en op dit moment heb ik een aantal leuke intermediate representations waarvan ik vermoed dat ze nuttig zijn. 1 van deze intermediate representations moet een combinatie worden voor directe geheugen-toegang en control-flow zodat er een betere analyse kan plaats vinden. Meestal wordt expliciet geheugen-gebruik gelijk met hogere control-flow constructies weggegooid: dat wil je dus niet.

Ik wilde dus een beetje kijken wat nuttige constructies zijn. Ik red me nu heel aardig voor mijn te compileren taal, maar goed: dat kan algemener . Het gaat dus in feite om een syntax-loze taal, maar goed een syntax zou later verzonnen kunnen worden.

Duidelijk? .

assembler wannabe

Wacht maar tot ik verder ben . Ik ben nog niet erg concreet met de assembly laag bezig geweest, maar wel met instructie-selectie. Ik moet me vooral nog meer verdiepen in de concrete architecturen....

[marcusk]

Interessant topic (vaag dat ik em niet eerder gezien heb)

Het gaat dus om een iets abstractere assembly vorm waar:
....
2. er geen variabelen zijn: je maakt direct gebruik van registers en geheugen

De management van variabelen lijkt mij juist iets dat goed door de compiler gedaan kan worden, omdat het in feite erg rechttoe-rechtaan is. (Register-allocatie is een ander verhaal )

Een tijdje geleden zat ik ook na te denken over een soort 'ASM/Java - hybride'. Het leek me echter toch niet zo'n goed idee omdat de 'trend' in programmeertalen juist gaat naar meer abstract, verder van de processor; Het vuile werk laten opknappen door de compiler + cpu ipv de programmeur

Vandaar dat ik nu probeer om een taal de maken die lijkt op Java (volledig OO, modulair, abstract) maar die naar native code gecompileerd wordt, als C++ (en hopelijk ook met een snelheid dicht bij die van C++) Ik ben nog niet zo ver, maar tot nu toe gaat het erg goed.

[mbravenboer]

marcusk: De management van variabelen lijkt mij juist iets dat goed door de compiler gedaan kan worden, omdat het in feite erg rechttoe-rechtaan is. (Register-allocatie is een ander verhaal )

Klopt, maar dat wordt ook door een andere fase van de compiler gedaan. De IR hierboven heeft gewoon variabelen. Ik denk echter dat deze tussen-fase erg interessant is voor talen die niet binnen het strakkere raamwerk van functies en methoden met variabelen passen, maar wel gebruik willen maken van eenvoudigere control-flow.

Bovendien is deze fase erg interessant voor optimalisering: met meer control-flow info kan je in principe veel beter optimaliseren. Omdat er in hogere niveaus nog geen expliciet geheugen-gebruik is, is dit een leuke andere optie...

Het leek me echter toch niet zo'n goed idee omdat de 'trend' in programmeertalen juist gaat naar meer abstract, verder van de processor; Het vuile werk laten opknappen door de compiler + cpu ipv de programmeur

Zeker, dat is absoluut zo, maar ja: het doel was ook eigenlijk niet om er concreet in te gaan programmeren zoals nu vast duidelijk is .

Vandaar dat ik nu probeer om een taal de maken die lijkt op Java (volledig OO, modulair, abstract) maar die naar native code gecompileerd wordt, als C++ (en hopelijk ook met een snelheid dicht bij die van C++) Ik ben nog niet zo ver, maar tot nu toe gaat het erg goed.

Cool , waar schrijf je de compiler in? Wat zijn de leuke voordelen van je taal boven Python/Java/C#?

[marcusk]

Op vrijdag 28 december 2001 00:01 schreef mbravenboer het volgende:
Zeker, dat is absoluut zo, maar ja: het doel was ook eigenlijk niet om er concreet in te gaan programmeren zoals nu vast duidelijk is

Nadat ik je reply op OiSyN nog eens goed heb doorgelezen is me dat nu wel duidelijk ja

Cool , waar schrijf je de compiler in? Wat zijn de leuke voordelen van je taal boven Python/Java/C#?

Ik gebruik C++ i.c.m. Flex en Bison (heb wel naar Stratego gekeken, maar daar begreep ik nog niet echt veel van ). Ben momenteel bezig met de code voor het opbouwen van de parse tree. Voor al die soorten expressies en (in mindere mate) statements representaties maken kost wel veel tijd

Een voordeel t.o.v. Python/Java/C# is dat het naar native code gecompileerd wordt, en dus sneller is (dat is de bedoeling althans). Verder heb ik ideeen voor kleine verbeteringen t.o.v. Java (Python en C# ken ik niet echt), maar het meeste daarvan is nu nog toekomstmuziek . Maar mijn doel is eigenlijk meer om te proberen een compiler te maken (ik ben nog niet zo lang bezig, maar heb er toch al veel van geleerd) dan om Java te verbeteren oid.

[mbravenboer]

marcusk: Nadat ik je reply op OiSyN nog eens goed heb doorgelezen is me dat nu wel duidelijk ja

Tsss, zomaar reageren zonder het topic te lezen .

Heb je nog ideeen over de oorspronkelijke vraag?

Ik gebruik C++ i.c.m. Flex en Bison

Aha... ik heb me ondertussen min of meer voorgenomen om nooit een compiler te gaan schrijven in een niet declaratieve-taal. Het is nog ff afwachten of ik dat ga volhouden .

heb wel naar Stratego gekeken, maar daar begreep ik nog niet echt veel van

Toch leuk dat je gekeken hebt . Helaas is Stratego bepaald niet newbie vriendelijk op dit moment. Er moeten veel en goede docs komen .

Het is er inderdaad wel erg geschikt voor en er is zelfs al een C back-end zodat je makkelijk naar C kan compileren . Ik ga waarschijnlijk nog werken aan een .NET IL en Java bytecode back-end...

Ben momenteel bezig met de code voor het opbouwen van de parse tree. Voor al die soorten expressies en (in mindere mate) statements representaties maken kost wel veel tijd

Idd, het is sowieso ook wel erg belangrijk om een geschikte abstracte syntax te verzinnen . Als die goed in elkaar zit, is alles een stuk duidelijker...

Een voordeel t.o.v. Python/Java/C# is dat het naar native code gecompileerd wordt, en dus sneller is (dat is de bedoeling althans).

Je moet wel ook garbage collection gaan implementeren... dat wordt misschien iets minder aantrekkelijk.... ?

Verder heb ik ideeen voor kleine verbeteringen t.o.v. Java (Python en C# ken ik niet echt), maar het meeste daarvan is nu nog toekomstmuziek .

Op zich wel leuk om ook ff naar Python, Ruby en C# te kijken als je tijd hebt zodat je ideeen kunt combineren en jatten .

Maar mijn doel is eigenlijk meer om te proberen een compiler te maken (ik ben nog niet zo lang bezig, maar heb er toch al veel van geleerd) dan om Java te verbeteren oid.

Snap, daar zijn er meer mee bezig .

[marcusk]

Op vrijdag 28 december 2001 00:47 schreef mbravenboer het volgende:
Heb je nog ideeen over de oorspronkelijke vraag?

Nee, sorry, ik ben nogal offtopic bezig dus

Aha... ik heb me ondertussen min of meer voorgenomen om nooit een compiler te gaan schrijven in een niet declaratieve-taal. Het is nog ff afwachten of ik dat ga volhouden .

Tot nu toe bevalt het me goed in C++. Maar eigenlijk is een groot gedeelte (de parser) geschreven in Bison BNF (of hoe die syntax ook mag heten), das ook een declaratieve taal toch?

Er moeten veel en goede docs komen .

Nogal ja De 'tutorial' die ik gelezen heb ging voornamelijk over het configureren van de tools, niet echt over de de taal zelf (Hoewel ik het wel beter snap door dat voorbeeld met de De Morgan regel enzo)

Ik ga waarschijnlijk nog werken aan een .NET IL en Java bytecode back-end...

Das kewl !

Je moet wel ook garbage collection gaan implementeren... dat wordt misschien iets minder aantrekkelijk.... ?

Ik heb nog niet echt over de GC nagedacht, maar het zal wel heel wat minder simpel zijn dan ik me voorstel Ik ben eigenlijk al blij als ik zo ver kom dat ik me daar echt mee bezig moet gaan houden

Op zich wel leuk om ook ff naar Python, Ruby en C# te kijken als je tijd hebt zodat je ideeen kunt combineren en jatten .

ok, dat ga ik zeker doen

* marcusk gaat nu

[mbravenboer]

marcusk: Nee, sorry, ik ben nogal offtopic bezig dus

Hum.... ik doe mee, het is mijn topic, dan mag dat toch wel? .

das ook een declaratieve taal toch?

Het ligt er aan wat je als declaratief ziet .

Dit heb ik ooit in een ander topic geschreven over declarativiteit:

Allereerst wordt Haskell vaak een declaratieve taal genoemd. Declaratief is echter een extreem slecht gedefinieerde notie. Wat is declarativiteit? Vaak wordt er gezegd dat een taal declaratief is als je niet beschijft hoe de computer iets moet doen, maar wat de computer moet doen. Een compiler moet dan maar uitvogelen hoe dit gedaan moet worden. Een imperatieve taal is volgens deze definitie geen declaratieve taal omdat je in feite exact opgeeft hoe een computer iets moet doen.

Eigenlijk vind ik dit geen aangename definitie. Ik vind namelijk dat een taal helemaal niet declaratief is in het paradigma van deze taal. Je geeft namelijk binnen het model van dit paradigma precies aan hoe iets moet gebeuren. Een taal is dan ook alleen declaratief ten opzichte van een ander paradigma. Functionele talen kan je daarom declaratief noemen ten opzichte van het imperatieve paradigme. Ten opzichte van dit paradigma geef je aan wat er moet gebeuren. In het paradigma van de taal zelf geef je aan hoe iets moet gebeuren. Omdat alle paradigma's worden vergeleken met het imperatieve paradigma worden vaak alle andere paradigma's declaratief genoemd. Mijn interpretatie nuanceert dat een beetje <http://gathering.tweakers.net/global/smileys/wink.gif> .

Mijn aangepaste definitie komt eigenlijk voort uit het bewijzen van programma-correctheid. Er wordt namelijk weleens beweert dat een programma geschreven in functionele taal geen bewijs nodig heeft voor correctheid. Dit argument komt voor uit de aanname dat deze taal declratief is en dus beschijft wat er moet gebeuren. Een bewijs van correctheid vergelijkt over het algemeen wat er moet gebeuren met hoe iets moet gebeuren . Als er alleen maar een 'wat er moet gebeuren' is, valt er natuurlijk ook niets te bewijzen! Maar goed, iedereen die ooit weleens in Haskell gewerkt heeft zal weten dat je ook daarin makkelijk een incorrect programma kan maken. Neem bijvoorbeeld een stukje code die een lijst zou moeten sorteren, maar dit niet goed doet. In principe is dit programma een vertaling vanuit een specificatie-paradigma: je geeft aan wat je wilt bereiken met het programma. Je geeft in Haskell code aan hoe dit moet gebeuren (let op het woordje 'hoe'!). Ik vind dat je altijd de correctheid van een programma moet bewijzen als je vanuit het ene paradigma op het andere paradigma over gaat.

Als je namelijk een 'wat er moet gebeuren' beschrijving hebt in een functioneel paradigma en je implementeert dit in een imperatief paradigma, dan heb je een bewijs nodig dat deze implementatie voldoet aan je specificatie. Als je echter een 'wat er moet gebeuren' beschrijving hebt in een functioneel paradigma en je implementeert dit in Haskell, dan is er geen bewijs nodig. Je blijft namelijk in hetzelfde paradigma, of anders gezegd: je specificatie is je implementatie.

Mijn opmerking over het bouwen van een compiler in een declaratieve was dus eigenlijk erg fout . Ik bedoelde eigenlijk meer een taal die speciaal ontworpen is voor het implementeren van programma-transformaties.

Nogal ja De 'tutorial' die ik gelezen heb ging voornamelijk over het configureren van de tools, niet echt over de de taal zelf (Hoewel ik het wel beter snap door dat voorbeeld met de De Morgan regel enzo)

Hum ja, er zijn wel ergens hele goede slides. Als je nog interesse hebt kan ik ze wel ff opzoeken. Als je het wilt gaan proberen kan ik uiteraard helpen .

Ik heb nog niet echt over de GC nagedacht, maar het zal wel heel wat minder simpel zijn dan ik me voorstel Ik ben eigenlijk al blij als ik zo ver kom dat ik me daar echt mee bezig moet gaan houden

Triviaal is het zeker niet . Maar met het bestuderen van wat stof, kom je er vast wel uit...

* marcusk gaat nu

* mbravenboer ook .

[marcusk]

Op vrijdag 28 december 2001 02:08 schreef mbravenboer het volgende:
Hum ja, er zijn wel ergens hele goede slides. Als je nog interesse hebt kan ik ze wel ff opzoeken.

Jazeker heb ik daar interesse in!

Als je het wilt gaan proberen kan ik uiteraard helpen .

Ok !

Triviaal is het zeker niet . Maar met het bestuderen van wat stof, kom je er vast wel uit...

oei, in [topic=362705/1/25] lees ik net dit:

Op vrijdag 28 december 2001 03:11 schreef packman het volgende:
Ik heb het eens bekeken - en dat is niet iets dat je op een maandje ineen knutseld... zeker als het nog een beetje performant moet zijn ook. We hebben veel geluk gehad dat we die gc zijn tegengekomen - anders hadden we een (serieus) memory probleem.

[mbravenboer]

marcusk: Jazeker heb ik daar interesse in!

Hier staan ze:
http://www.stratego-language.org/twiki/bin/view/Stratego/StrategoDocumentation
De slides (onderaan) zijn erg duidelijk en ik vermoed dat je daar wel min of meer uit kunt komen. Voor vragen kan je natuurlijk hier terecht . De Stratego-compiler is geschreven in Stratego en bevat het cgen package, waarmee je makkelijk C kunt genereren.

oei, in [topic=362705/1/25] lees ik net dit

Hehe . Voor eenvoudige situaties kan het wel wat makkelijker, maar ik vrees dat jouw taal geen eenvoudige situaties wordt .

[marcusk]

Op vrijdag 28 december 2001 13:31 schreef mbravenboer het volgende:
Hier staan ze:
http://www.stratego-language.org/twiki/bin/view/Stratego/StrategoDocumentation

bedankt! ik ben al aan het lezen

Hehe . Voor eenvoudige situaties kan het wel wat makkelijker, maar ik vrees dat jouw taal geen eenvoudige situaties wordt .

oh jee