abainbridge

> I think the op is far too pessimistic about code size and performance

My code gen is definitely worse than TCC! But I think modern CPUs see all my redundant register-register moves and just treat them as a no-ops. Probably performance isn't much worse than TCC. But currently I can hardly compile a program complex enough for a meaningful comparison to be made.

> I think the viewpoint that your're missing is: how do I make sure the machine code means the same thing as the source code?

Ooo, no. I already have an AST. When writing the code gen for a node type in the AST, I normally start by typing a few lines of C into godbolt that exercises the same kind of thing represented by the node type. I try a few different compilers and optimization settings and look at what gets generated. I pick an approach that looks simple and good enough. Then I ask an AI to assemble the instructions I see the compilers using. I like to ask an AI to do this because it will explain what all the bits do in the instruction encoding and it is less error prone at reading the ISA docs than I am. The description from the AI might prompt me to ask things like, "what if the jump target doesn't fit in the 32-bit immediate" etc.

All I was claiming was that this is easier than generating code for a byte code of my invention, partly because I don't have to invent a byte code and partly because I can use existing tools to help, eg disassemblers/debuggers to check my output or compilers to give me ideas on how to convert C-like statements into machine code.

I don't have any IR at the moment. I'll have a think about what benefits that might bring.

The reason I posted my project under this top level thread is because I'm interested in Small Programs and Languages. My experiment is in what I can remove from a language implementation to make it simpler. Adding a dependency on LLVM is the opposite of what I had in mind :-)

There are many reasons I'm writing it in C but mainly because I like C.

I didn't know about the Appel book. I'll take a look. Thanks.

I feel like the way we write about compiler design could be reduced in complexity too. I read the blog posts by Nora Sandler and they did a great job compared to "the Dragon book" (confusing now because her book has a dragon on the front too). But we still ought to replace phrases like "lexical analysis" with "character grouping" (credit to Sam H Smith for forcing that one into my brain).

> What I understand from that is, byte code is portable while machine code isn't.

This is an area I want to explore. It seems to me that it is less true than it used to be. x86_32 was the last significant architecture that made things hard. Now we can ignore that. All desktop or server class CPUs support 8, 16, 32 and 64-bit integers. And they all have at least 10 general purpose registers. They all have a sensible set of memory access modes. As a result, the same code generator works for them all. As it stands, my code generator calls functions like emit_indexed_load, emit_conditional_jump etc. There are currently 26 of those functions and they're all trivial.

So far I have only implemented them for x86_64 machine code output. But writing versions that output ARM64 or risvc doesn't seem hard. I expect I'll find small problems which will cause me to have to tweak the set of CPU features my code gen depends on.

As for generating bytecode being easier than x86_64 machine code, I disagree. There are lots of tools for validating x86_64 machine code (ie disassemblers). There aren't any for a bytecode I might invent. And I can ask an AI how to generate x86_64 machine code to do an indexed load. I immediately get the answer. I don't have to think about how to make an efficient bytecode encoding.

The hardest thing I've encountered so far is getting the ABI right so that my compiled code can call existing functions (eg libc). But I'd have to do that even if I was using an interpreter.

TCC is partly what motivated me to try. But I want to get closer to lower the Kolmogorov Complexity. I'm happy to sacrifice C compatibility. In fact I'm happy to sacrifice much of the power of C. And I'd be happier with code that was somewhat slower.

And the original TCC code is not easy to understand. It is a lot cleverer than I can cope with!

Hah. I won't pretend I'm not motivated by the same forces as many lost souls before me. But if my language turns out anything like Lisp, I'd be upset.

Hadn't seen Cozette before. Its lovely. Ta.

That's awesome. Now what I want is an animated version that shows how the bugs lines change over time.

I want to see the same graph but for number of CVEs introduced. ie, when we find a CVE, find out which kernel version introduced it. This would only be useful for kernel versions that were a few years old, so we'd have had time to find most of the CVEs. But it'd still be interesting.

Yes. I don't really understand why Zig gets more attention than dlang. It seems that it is more to do with the personality of the authors, rather than the technicalities. I get the impression that Walter is more laissez-faire, while Andrew is more single-minded. I'm grateful to the contributions both have made.

Another point I liked was that there was, apparently, an influential book called Structured Programming, whose content was so universally agreed upon, that all programming became Structured Programming. Nobody needs the book anymore.