3 ms·

I have written multiple compilers, from C-like interpreters to protobuffer like compilers over the years, all in production, some still. Not doing a finite sta

by mianos 3y ago

I have written multiple compilers, from C-like interpreters to protobuffer like compilers over the years, all in production, some still. Not doing a finite state machine for any stream interpretation is a huge mistake, just as much as it is outside of the compiler tokenisation, such as protocol decoders and even just parsing config files. edit: There is a well known book with a dragon on it, but I first learnt from The Unix Programming Environment, by Brian W. Kernighan and Rob Pike. In just a few pages they clearly explain how to write an basic calculator like this, that generates intermediate code to run on a stack based interpreter. I started with this and expanded it to emit assembly for an arcane DG machine. I know that code generated ran for at least 20 years. Kinda surreal as nothing lasts that long usually.

musicale 3y ago
Could you elaborate on what you mean by that? To me this looks like a code generation library, an approach I like because of its concreteness and adaptability (for example, if we changed it to emit opcodes then it could be used for dynamic code generation, which has many fun and interesting applications.) Also this post is aimed at the author's imagined teenage self. Does that change anything?
- mianos 3y ago
  When writing a compiler you want to first look at what you expect and when you get that, what to expect next. If that does not come, where do you go? We call this a graph, but there is no need to confuse things with advanced terms.
  - musicale 3y ago
    I don't see any parsing in TFA - I think they are taking a bottom-up approach by starting with a code generation library before even thinking about parsing. I like this approach because it produces something that generates usable code without worrying about things like parsing or high level language syntax, and you've basically written a DSL/intermediate format which can be compiled by an existing C compiler.
globalnode 3y ago
thanks for the edit, i will endeavor to have a look at that source

by mianos 3y ago

musicale 3y ago

Could you elaborate on what you mean by that? To me this looks like a code generation library, an approach I like because of its concreteness and adaptability (for example, if we changed it to emit opcodes then it could be used for dynamic code generation, which has many fun and interesting applications.) Also this post is aimed at the author's imagined teenage self. Does that change anything?

mianos 3y ago
When writing a compiler you want to first look at what you expect and when you get that, what to expect next. If that does not come, where do you go? We call this a graph, but there is no need to confuse things with advanced terms.
- musicale 3y ago
  I don't see any parsing in TFA - I think they are taking a bottom-up approach by starting with a code generation library before even thinking about parsing. I like this approach because it produces something that generates usable code without worrying about things like parsing or high level language syntax, and you've basically written a DSL/intermediate format which can be compiled by an existing C compiler.

globalnode 3y ago

thanks for the edit, i will endeavor to have a look at that source