Earlier quoted context omitted.
As Bill Gates was alleged to have said "640k ought to be enough for anybody."
He did not say that, sorry.
but he was alleged to !
Let's Build a Compiler
21–30 of 48 posts
Re: Let's Build a Compiler
#22We live in a world were ever PC has at least 2 Gbyte of ram and most CPU's are 64 bits, the section 'Data Representation' begins to explain how 'everything' can be stored in a single 32-bit integer, if we limit integers to 30 bits. What the hack?
It's premature optimisation... Java has conditioned everyone to believe that boxing variables is slow.
Re: Let's Build a Compiler
#23Earlier quoted context omitted.
Most CPUs aren't in self-hosting systems.
Yes they are. Embedded applications outnumber top end computers by an order of magnitude.
Perhaps he means that they are not generally self-hosted, in that we generally tend to cross-compile for the embedded hardware, rather than compiling on the embedded hardware.
Re: Let's Build a Compiler
#24Haven't started reading yet, but I'm really digging this trend of syntax-highlighted bare text blogs[0]. Is this a template or is it hand-crafted? [0]: https://christine.website/blog/h-language-2019-06-30
Not related to this site, but my site is "hand-crafted':
http://www.oilshell.org/site.html
And yes one of the main things I had to integrate myself was syntax highlighting (via pygments).
FWIW, I think proportional fonts for text and fixed width for code is more readable.
A few people asked me about the tools, and I dumped them here (but they are not supported, may not be runnable):
https://github.com/oilshell/blog-code/tree/master/tools-snap...
Re: Let's Build a Compiler
#25This looks like something similar to Crenshaw's excellent tutorial of the same name: https://compilers.iecc.com/crenshaw/ and its x86 port: https://github.com/lotabout/Let-s-build-a-compiler As interesting as Lisp-family languages are, I still think it's better to use something with more traditional syntax and start with parsing, because that both reaches a much wider audience and gives a very early introduction to t…
I think I partially agree, but that it mainly depends on the audience. I've found that parsing and recursion appear in more areas than just compilers, to the point where it'd be relatively difficult to avoid them. Machine code generation and the underlying implementation of high-level primitives (closures, tail-call recursion, and the like) hasn't, at least in my experience, been "naturally-occurring" to the same extent.
In terms of creating a "learn compilers from scratch" resource, Crenshaw's approach is definitely better. The trade-off would be that it'd take longer to get past the "writing a recursive descent/LR parser" phase, and it might never get to higher-level language features at all depending on the input language you go with.
Re: Let's Build a Compiler
#26Earlier quoted context omitted.
But he did say we wouldn't likely see speeds in excess of 64kbps. I save that article for decades, still have it somewhere in a filing cabinet, even though it's been scrubbed from the internet. He was referencing the limitations of copper POTS, of course. But I still found it funny (if I recall correctly, it was printed side-by-side with his debunking of the 'you only need so much ram' quote).
64kbps was a limitation of old analog phone lines, which were pretty noisy and also also operated at a pretty low frequency (they only allowed up to a certain frequency, anything beyond was clipped on old analog lines). In practice, dont know that I saw anything beyond 56k. And you could only get that on a clean line, near a switching station. My self, not sure I ever saw much beyond 48k, maybe occasionally 52k, but…
My top dial-up speed was 46.6 kbps (not sure if kilobytes or kibibytes)
Re: Let's Build a Compiler
#27I have attempted following Ghuloum's paper, too. One difference is I wanted to make it as self-contained as possible and didn't want to depend on a C compiler or binutils. So I wrote a simple assembler. Here it is, all in Clojure:
https://github.com/nathell/lithium
It's dormant – I was stuck on implementing environments around step 7 of 24 – but someday I will return to it and make progress.
Re: Let's Build a Compiler
#28We live in a world were ever PC has at least 2 Gbyte of ram and most CPU's are 64 bits, the section 'Data Representation' begins to explain how 'everything' can be stored in a single 32-bit integer, if we limit integers to 30 bits. What the hack?
Generating 64-bit code would be simpler in many ways, but I decided not to go into it until the basic language features are put in place. The extent of the changes involved in switching to amd64 will help directly show why having an intermediate representation for the generated code would be valuable. Besides, if you're looking for a high-performance Scheme that fully utilizes all available system resources, there ar…
For your initial design you could also have chosen to use an additional byte to represent the type of the value. As representing the type would only require 2 or 3 bits, some bits will be unused (probably some more, due to alignment requirements), but maybe later on in the development of the compiler, those bits could be used to store some additional information. That would have made your code a lot simpler.
As you probably want to combine these valuse together into some structures representing the various language constructs, an additional byte to represent the type of the structure, and thus the type of its elements, would also be needed. Than you could do away with the extra bits representing the type.
I just think this is premature optimization and making things unneccessary complex especially for your readers who might want to learn something from it.
Re: Let's Build a Compiler
#29Earlier quoted context omitted.
Generating 64-bit code would be simpler in many ways, but I decided not to go into it until the basic language features are put in place. The extent of the changes involved in switching to amd64 will help directly show why having an intermediate representation for the generated code would be valuable. Besides, if you're looking for a high-performance Scheme that fully utilizes all available system resources, there ar…
For your initial design you could also have chosen to use an additional byte to represent the type of the value. As representing the type would only require 2 or 3 bits, some bits will be unused (probably some more, due to alignment requirements), but maybe later on in the development of the compiler, those bits could be used to store some additional information. That would have made your code a lot simpler. As you p…
The types of user-defined "structures" are usually identified by a tag inside the structure, not encoded in the pointer as for the few primitive types.
Re: Let's Build a Compiler
#30it puzzles me sometimes why we programmers are so fascinated by compilers, interpreters, VMs, runtimes, etc. many of these will never make it to the level of, say, a production c++ compiler or a Java VM. and yet we keep building small compilers.