Follow

My little Lisp interpreter can now perform arithmetic operations.

Exciting!

Β· Β· Web Β· 2 Β· 2 Β· 14

Managed to get lambdas and closures working in my language. I feel all-powerful now ⚑

Probably a bad implementation but I'll clean it up as things progress. Likely will stay messy until I have a garbage collector running.

@bd I'm curious to hear your goals with this!

Here are mine: akkartik.name/post/wart; github.com/akkartik/mu/tree/ma. I suspect you might have a couple earlier ones of your own..

@akkartik just experimenting for now, my goal is to understand better different moving parts of a programming language. The idea would be to get a full bootstrap interpreter going and then learning to generate x86_64 or ARM assembly after I got a self hosted compiler from it.

Additionally I want to be able to freely interop with C or ASM code and have ways of allocating and processing arrays for better performance.

@bd Nice. I've never gotten to a Lisp compiler. CPS transforms and all that stuff.

@akkartik me neither! Which is why I’m exploring the area right now ;)

I’m case you are interested in something like that I found this very nice paper on the matter: scheme2006.cs.uchicago.edu/11-

@bd Yeah, good ol' Gholoum is a classic. I have a slightly unconventional[1] opinion there. Gholoum and the whole nanopass idea is useful only if you're building your compiler in a HLL. (Which.. why would you?! IMHO.)

[1] My PhD was partly in compiler design. It took me 10 years to realize it didn't teach me very much at all about the subject.

@bd Compiler in a HLL makes a lot of sense for a prototype. But I have this whole belief system that production compilers (i.e. stuff people write code for) for HLLs built in other HLLs add a lot of noise to civilization's supply chains.

@akkartik yeah I mean I love to be closer to the metal myself. Building everything in C these days. I may hit you up for questions once I get this a bit more advanced haha.

@akkartik to be honest I started this exploration because I was wondering if I could compile a rom directly to assembly but I thought it would be nice to study the entire thing fresh.

A stack based language can actually be translated much easier to assembly it seems since I could just use the SP but this is also an opportunity for me to up my lisp-fu game.

@bd Stack based compilers have almost a whole other parallel track of papers, I believe. @vertigo might have some guidance for you.

@akkartik @bd Perhaps there exists some kind of issue with how HT follows merveilles.town, as I cannot see the discussion thread.

@akkartik @bd I don't really have any papers which come to mind right off hand.

Most Forth "compilers" are byte-code, direct-, indirect-, or subroutine-threaded implementations with precious little in the way of optimization. So, they err on the side of simplicity at the expense of performance.

@vertigo @bd I think I really just meant "scholarship" rather than papers. Ways of optimizing like using a register file as a stack.

@akkartik @bd Ahh. About that. I have lots of theories in my head, but no concrete practice, because I keep getting side-tracked in my projects. ;)

But, if you have enough registers, and you aren't afraid of letting the compiler keep track of some meta-data during compilation on a "compile-time stack" of sorts, it should be doable for most RPN-expressible programs.

@vertigo @akkartik This is really my first foray into building a full interpreter + compiler so I think I'll likely leave the optimizations passes for later.

For now I'm not working on the stack -> assembler, but my worry with using the SP is that maybe it could get dirty if we call for some syscalls or things like that? I have no idea TBH.

@bd @akkartik One way to work around this is to use "thunks", a group of routines whose sole purpose is to interface to the system call interface.

Another approach is to isolate the data and return stacks, which is how Forth does things.

@vertigo @akkartik @bd and most optimising Forth compilers are commercial products, so their source isn't available for study

Stephen Pelc wrote a very quick drive-through of the structure of VFX, but there's not much to glean from here: euroforth.org/ef00/pelc00a.pdf

and Anton Ertl has done some work on optimising threaded code - his papers are all at complang.tuwien.ac.at/projects (or follow links from there to his other bits)

occasionally, efforts at optimising Forth compilers have escaped into the public domain - for example Lars Kreuger's flk, which is available at complang.tuwien.ac.at/forth/ but very dusty and unmaintained, or Marcel Hendrix's mxForth home.iae.nl/users/mhx/mxforth. which is even dustier

for optimising compilation of stack based languages in general, the Self papers and the work on Java JITs are probably the richest seams to mine

Sign in to participate in the conversation
Merveilles

Revel in the marvels of the universe. We are a collective of forward-thinking individuals who strive to better ourselves and our surroundings through constant creation. We express ourselves through music, art, games, and writing. We also put great value in play. A warm welcome to any like-minded people who feel these ideals resonate with them.