31–40 of 48 posts
Haven'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
it 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.
it 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.
it 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.
Not all those who consider themselves programmers necessarily come from a CS background and so don't learn about concepts like these. To them, walkthroughs like these are fascinating.
Earlier quoted context omitted.
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.
As I said further down this thread though, it's a 'speed' thing, not memory storage thing, the common belief is that boxing is slow, because it was slow in java, but in reality boxing is a) a mostly acceptable trade-off that only loses out in extreme cache-limited situations, and b) something that could be optimised away anyway.
it 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.
It just helps fully understand how you go from words in a file to actually doing computations and how purely abstract ideas like a 'class' are implemented.
To be fair, I studied Physics and not CS so I didn't have the opportunity to study Compilers at University.
This 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…
Not everything needs to be on a so-you-have-never-programmed-before level. This series explicitly assumes "some knowledge of native-code build processes, Lisp, C, and x86 assembly language". People who know Lisp should have had an introduction to thinking recursively already.
Parsing would be a useless distraction for someone interested in writing a Scheme compiler in Scheme.
Earlier quoted context omitted.
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.
You'd probably be surprised how many GC'ed languages actually avoid the whole tagged/boxed variable thing in pursuit of the performance benefits. ocaml for example is limited to 30bit ints for this reason, the haskell standard only guarantees 30bits from the 'Int' implementation for this reason. As I said further down this thread though, it's a 'speed' thing, not memory storage thing, the common belief is that boxing…
I agree that a lot of boxing can be optimized away, but often it also can't.
it 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.
I did the Nand2Tetris course which includes building a basic compiler. It just helps fully understand how you go from words in a file to actually doing computations and how purely abstract ideas like a 'class' are implemented. To be fair, I studied Physics and not CS so I didn't have the opportunity to study Compilers at University.
Lots of CS people haven't either. My university moved compiler theory to the Masters program.
It's a work in progress, but very well made. I think Bob (who is writing the book) is a great educator.