21–30 of 44 posts
I'm actually working on a Pascal compiler right now. Register management has been a really tricky part for me, but I didn't even thing of treating an x86 processor as a stack based machine. Very clever, especially when you just want a simple compiler an not anything super optimized.
Details are described in the book Write Your Own Compiler, http://t3x.org/t3x/book.html
I'm currently working on a 3-part blog series on writing a one-pass compiler in Python that emits C. It is quite a bit longer though because we make the lexer and parser from scratch. I started it because my students were having trouble with other tutorials because of all the jargon, theory, and libraries required. http://web.eecs.utk.edu/~azh/blog/teenytinycompiler1.html
The author states: >"An optimizing compiler would constant-fold our expression into a single number ahead of time." Could someone say what is meant by constant-folding here?
As a concrete example I wrote a simple interpreter a while back, in golang. Operations would be compiled to a simple bytecode which would be executed at runtime. So: 3 + 4 Would get "compiled" to: PUSH_INT 3 PUSH_INT 4 OP_PLUS As you can imagine this was a virtual stack-machine. After a while I started folding these operations: * If there was a "push int" * And another "push int" * And a maths operation. * Then repla…
I'm currently working on a 3-part blog series on writing a one-pass compiler in Python that emits C. It is quite a bit longer though because we make the lexer and parser from scratch. I started it because my students were having trouble with other tutorials because of all the jargon, theory, and libraries required. http://web.eecs.utk.edu/~azh/blog/teenytinycompiler1.html
I've done the same thing for the same reason but in JavaScript and compiling a lisp dialect. https://notes.eatonphil.com/compiler-basics-lisp-to-assembly...
https://gist.github.com/cellularmitosis/1f55f9679f064bcff029...
Earlier quoted context omitted.
As a concrete example I wrote a simple interpreter a while back, in golang. Operations would be compiled to a simple bytecode which would be executed at runtime. So: 3 + 4 Would get "compiled" to: PUSH_INT 3 PUSH_INT 4 OP_PLUS As you can imagine this was a virtual stack-machine. After a while I started folding these operations: * If there was a "push int" * And another "push int" * And a maths operation. * Then repla…
For anyone wondering, the NOPs are so that jumps don't get messed up. Assembly level GOTOs generally work on byte/word offsets, so if something intended to jump back before the calculation but was expecting two PUSH_INTs and an OP_PLUS (5 words: 3 opcodes, 2 arguments) but there was only a single PUSH_INT (2 words), it would jump back 3 words too far.
Later I do walk back over the bytecode and remove the nops. But I have to update all JMP/CALL instructions to cope with the changed destination offsets. Not a hard job in my case, as there are only a couple of instructions which refer to byte-offsets.
(If I allowed "LD A,[BC]", or similar permuations I'd have a lot more work to do.)
Tangential - in your work in progress compiler book https://keleshev.com/compiling-to-assembly-from-scratch-the-... are you going to write yourself the lexer and parser or use Flex and Bison like in the article ?
I'm currently working on a 3-part blog series on writing a one-pass compiler in Python that emits C. It is quite a bit longer though because we make the lexer and parser from scratch. I started it because my students were having trouble with other tutorials because of all the jargon, theory, and libraries required. http://web.eecs.utk.edu/~azh/blog/teenytinycompiler1.html
That's very well done, thanks for sharing. I really like the straight forward writing style, I've never attempted to write a compiler, and have only done basic parsers for day to day tasks, so like the clean, simple approach.