Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a C Compiler: Build a Real Programming Language from Scratch

nostarch.com

Post reply on HN
Print view View original

91–100 of 159 posts

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#91

Post by jsnnsjxj »

materielle wrote: post #62
hdbxbxndj wrote: post #30

Earlier quoted context omitted.

OCaml is one of the most used languages for compiler design A good engineer should be able to use the right tool for the job

For hobbyist compiler implementations, right? Compilers for the most popular languages are either written in C/C++, or self-hosted. You can write compilers in almost any language. I fail to see how C, C++, or even Java or Python aren’t the right tool for the job here. I like pattern matching too, but given that hundreds of successful production compilers have been written without pattern matching, it’s surely just a…

I mean, we _are_ talking about a book which invites you to build your own toy C compiler ^^

Nevertheless, OCaml is very strong in compiler design. For example Rust and Hack were written in OCaml initially.

Nevertheless you are not wrong that compilers needing the very last bit of performance like the JVM and LLVM tend to be written in C++

But the barrier is quite a lot more tending to high performance/very high performance and not toy/production

Java and Python are suitable for implementing a toy Compiler and the auther invites you to use any language you like. Just the reference implementation is using OCaml

I would however argue that using C++ is quite advanced since it does not have pattern matching and using C is just masochm. You will be fighting against the language to do even trivial things instead of fighting the actual problem at hand

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#92

Post by jsnnsjxj »

viraj_shah wrote: post #73

Dropping this one here! (no affiliation) https://www.linuxfromscratch.org/ "Linux From Scratch (LFS) is a project that provides you with step-by-step instructions for building your own custom Linux system, entirely from source code."

This has nothing to do with the post?

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#93

Post by jsnnsjxj »

alok-g wrote: post #35
hdbxbxndj wrote: post #31

Earlier quoted context omitted.

Writing an simple assembler is trivial. Even macro assemblers are very easy. However, it's also boring. Nevertheless the contents of the book cover all the techniques required to write an assembler, if you'd really like to

I understand that assembly file can be parsed in the same way. However, I want to learn about the machine instructions to the level of bits, and likewise the layouts of binary files. Unless I am able to go all the way to machine code loaded in memory, I would not know where in memory to add a breakpoint instruction when a developer wants the same on a line of code. If there is some library that can help create machin…

Building a debugger and profiler is quite an advanced task compared to building an assembler though ^^

Also much of that work is heavily dependent on the used operating system.

Nevertheless, I'm wishing you all the best on your journey!

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#94

Post by stefanos82 »

vulcan01 wrote: post #68
stefanos82 wrote: post #46

Earlier quoted context omitted.

Correct me if I'm wrong, but I think both Zig and Jai use LLVM as their default backend...at least, that's what I have seen via live streaming for Jai, and from Zig's repo.

Zig is moving away from LLVM ( https://github.com/ziglang/zig/issues/16270 ) and Rust has added Cranelift as a debug backend ( https://lwn.net/Articles/964735/ ). Not sure about Jai.

I don't think it's moving away, because if you have read the entire thread, the gaming community reacts negatively to say the least and they assure everyone that LLVM does not going anywhere any time soon.

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#95

Post by kragen »

userbinator wrote: post #39
Croftengea wrote: post #23

Earlier quoted context omitted.

> Parser-generators were always academic projects Were they? GCC abandoned bison in favour of their own parser relatively recently.

"relatively recently" as in around 20 years ago, in GCC 3.x according to sources I found.

gcc was first released in 01987, but it didn't replace its bison parser for c until gcc 4.1 https://gcc.gnu.org/gcc-4.1/changes.html which was in 02006 https://gcc.gnu.org/releases.html, only 18 years ago, and 19 years after it was released. joseph myers first proposed doing this in 02004 https://gcc.gnu.org/legacy-ml/gcc-patches/2004-10/msg01969.h...

so gcc has literally been using a parser-generator-generated parser for c for more than half its existence, at which point it had already become the most popular c compiler across the unix world and basically the only one used for linux, which had already mostly annihilated the proprietary unix market. it was also imposingly dominant in the embedded space

and i think that kind of development path is fairly typical; getting a parser up and running is easier with a parser generator, but it can be tricky to get it to do strange things when that's what you want (especially with lalr, less so with peg)

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#96

Post by kragen »

wrycoder wrote: post #75
signaru wrote: post #25

Have read the first few chapters and it expects that you either read the accompanying source code or implement your own and pass the tests. The pseudo code presented in the book often look like function calls with the inner details not there in the book. Furthermore, as already pointed out in another comment, the available implementation is in OCaml, which is probably not something many C programmers have experience…

Nand2Tetris is also like that - they provide an outline and tests, but you have to do the work. And, having the implementation language be different from the target language reduces confusion. Plus, you get to become proficient in OCaml, which is a pretty good language.

that's a good point—it was pretty confusing when i wrote ur-scheme in scheme, or stoneknifeforth in stoneknifeforth, because i kept getting confused about which level of the language i was changing things in

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#97

Post by kragen »

auselen wrote: post #29
thechao wrote: post #19

Earlier quoted context omitted.

When your computer was anemic, and could barely do the tasks required for it, eking out a few percent — or a 2x! — from an optimizer was important. Now-a-days, the difference between "big compiler optimized" and "little compiler not optimized" can be quite dramatic; but, is probably no more than 4x — certainly within range of the distinction between "systems programming language" and "high tuned JITted scripting lang…

Wouldn’t just a simple case of bad code generation render little compiler into a toy one? Repeating others, today’s compilers are really just “optimizing compilers”, there is no room for toying in production environments.

if you aren't running on the gpu you're leaving 80+% of your computer's performance on the table. no optimizing compiler is going to make your legacy c or lisp or rust code run efficiently on the gpu, or even in most cases on a multicore cpu. nor, as thechao points out, can it compete with assembly-language programmers for simd vectorization on the cpu

in summary, optimizing compilers for c or pascal or zig or rust or whatever can only be used for code where considerations like compatibility, ease of programming, security, and predictability are more important than performance

probably the vast majority of production code is already in python and javascript, which don't even have reasonable compilers at all

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#98

Post by tuveson »

jerjerjer wrote: post #82

I uh misread the title and thought someone built a C compiler in Scratch. On topic, though: wouldn't a simpler language (maybe even a pseudo language) be a better target for a first learning compiler. I understand they don't build a full C compiler, but still. It looks to me like there's a lot of complexity add from choosing such a lofty target.

What do you think would make a better target? C maps pretty closely to assembly, so it seems like it would be the simplest. Maybe Pascal or BASIC, but most people these days don’t have experience with Pascal, and BASIC would probably be too simple for a full-length book.

For writing an interpreter or transpiler, there are probably better options, but for a true compiler I can’t think of a better choice than C (or at least a subset of C).

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#99

Post by auselen »

kragen wrote: post #97
auselen wrote: post #29

Earlier quoted context omitted.

Wouldn’t just a simple case of bad code generation render little compiler into a toy one? Repeating others, today’s compilers are really just “optimizing compilers”, there is no room for toying in production environments.

if you aren't running on the gpu you're leaving 80+% of your computer's performance on the table. no optimizing compiler is going to make your legacy c or lisp or rust code run efficiently on the gpu, or even in most cases on a multicore cpu. nor, as thechao points out, can it compete with assembly-language programmers for simd vectorization on the cpu in summary, optimizing compilers for c or pascal or zig or rust o…

How come you made this about computer’s performance :)

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#100

Post by auselen »

bigstrat2003 wrote: post #89
auselen wrote: post #78

Earlier quoted context omitted.

Ok, but that’s sw engineering issue. I still insist that a production grade compiler can’t leave performance on table. Which is where the current battlefield is.

I think a production grade compiler not only can, but must, leave performance on the table when the cost is correctness (unless the performance gain is incredibly high and the correctness loss is minimal). Correctness is not all important, but it is the most important thing. Unfortunately, compiler writers do not agree and they do silly things like "let's assume UB cannot ever happen and optimize based on that".

Correctness is already a must, how did you arrive to this?
Post reply on HN