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

51–60 of 159 posts

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

#51

Post by rramadass »

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…

Checkout GNU Binutils and their usage of libbfd and libopcodes.

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

#52

Post by alok-g »

synack wrote: post #49
alok-g wrote: post #22

I would love to see a book that talks about going all the way to generate machine code, i.e., not stopping at generation of assembly. Alternatively, I would like to learn about not just how to make a compiler, but also simultaneously a debugger, hot-reloading, etc.

The debugger book is coming soon. https://nostarch.com/building-a-debugger

Awesome! Thanks.

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

#53

Post by alok-g »

fuhsnn wrote: post #37
alok-g wrote: post #35

Earlier quoted context omitted.

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…

>If there is some library that can help create machine code from assembly instructions on a line by line basis That's what JIT libraries do, for example asmjit: https://github.com/asmjit/asmjit/blob/master/test/asmjit_tes...

Looks cool! Thanks.

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

#54

Post by kragen »

mjburgess wrote: post #43
kragen wrote: post #27

Earlier quoted context omitted.

yacc/bison was used for lex, bc, pcc, gcc, original awk, the bsd pascal compiler, eqn, m4 (!), and many other languages. it's still used for pcc, oawk, mawk, pari/gp, and units. that's just what i have sitting around in my downloads directory and, while we're talking about ocaml, ocaml does use ocamllex and ocamlyacc for its own parser so, while you can certainly do without parser generators, they have very commonly…

I guess I wasn't very clear. I didnt mean to say, as a historical matter, were irrelevant. I meant to say the idea of a parser generator is a solution to a problem that that real world langs don't really have. When writing a programming language, your issue isnt how much time the parser is going to take to write, or how complex it's going to be. The parser is a relatively trivial part of the problem. Due to language…

oh, i agree that parsing is not the hard part of writing a compiler, and that compilers classes overemphasize it

but no language starts out as a 'real world lang'; every language is initially a toy language, and only becomes a 'real world lang' in the unlikely case that it turns out to be useful. and parser generators are very useful for creating toy languages. that's why virtually every real world lang you've ever used was implemented first using a parser generator, even if the parser you're using for it now is handwritten

having a formally defined grammar is also very helpful for dx features like syntax highlighting and automated refactoring

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

#56

Post by fuhsnn »

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.

>just a simple case of bad code generation render little compiler into a toy one

If you find some time to go through gcc bugzilla you'll find shockingly simple snippets of code that miscompiled (often by optimization passes), with fixes never backported to older versions that production environments like RHEL are using.

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

#57

Post by kragen »

shortrounddev2 wrote: post #41
kragen wrote: post #24

Earlier quoted context omitted.

ocaml makes writing a compiler enormously more accessible, and learning to read ocaml, while it can be somewhat intimidating at first, is much easier than learning to write a compiler (imagine a medieval accountant trying to learn to do long division in roman numerals. he'll be much better off learning the western arabic numerals fibonacci is so excited about)

I really really really want to get more into Ocaml but as far as I know there is no good support for a debugger to use in an IDE like VSCode or even vim. Everyone I talk to says they just do print debugging. It's easier to 'reason about your code' in FP, but I do NOT want to go back to a time where I coded without breakpoints. I use F# because of its first party tooling support

it does have a debugger with breakpoints, which even supports time-travel debugging (except on windows obviously), but i've never used it. it even has first-party ide integration: https://ocaml.org/manual/5.2/debugger.html#s:inf-debugger

i use debuggers a lot when i'm programming in assembly, and from time to time when i'm programming in c or c++, but in ocaml i've never needed one. it's not that i've never had bugs in ocaml, but they tend to be of a different flavor, a flavor for which breakpoints are of little value

it sounds like your f# experience is different; what kinds of bugs have you recently found the debugger valuable for in f#?

debug logging is usually a superior option to breakpoint debugging for problems to which both are applicable, because debug logging shows you the whole history of your program's execution rather than just a single point in time. breakpoint debugging requires a lot of manual labor, painstakingly operating the machine to navigate the execution to the state that has the problem. it's like grinding in a video game. i'd rather program the computer to do that labor for me, at which point i no longer need the debugger

(except in c and assembly)

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

#58

Post by layer8 »

mjburgess wrote: post #43
kragen wrote: post #27

Earlier quoted context omitted.

yacc/bison was used for lex, bc, pcc, gcc, original awk, the bsd pascal compiler, eqn, m4 (!), and many other languages. it's still used for pcc, oawk, mawk, pari/gp, and units. that's just what i have sitting around in my downloads directory and, while we're talking about ocaml, ocaml does use ocamllex and ocamlyacc for its own parser so, while you can certainly do without parser generators, they have very commonly…

I guess I wasn't very clear. I didnt mean to say, as a historical matter, were irrelevant. I meant to say the idea of a parser generator is a solution to a problem that that real world langs don't really have. When writing a programming language, your issue isnt how much time the parser is going to take to write, or how complex it's going to be. The parser is a relatively trivial part of the problem. Due to language…

The one thing parser generators do is that they ensure that the language you implement actually matches the grammar you wrote. That’s still an important assurance to have.

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

#59

Post by myth_drannon »

rramadass wrote: post #26
i_don_t_know wrote: post #7

Somewhat unrelated: Is there a book that walks you through building a database system from storage to queries, optimizer, execution, indexing, transactions, etc?

In the early 90's Al Stevens wrote 2 books C Database Development and C++ Database Development with source code which might be a good starting point.

Interesting suggestion! here is the book on archive.org: https://archive.org/details/cdatabasedevelop00stev/mode/2up

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

#60

Post by kragen »

layer8 wrote: post #58
mjburgess wrote: post #43

Earlier quoted context omitted.

I guess I wasn't very clear. I didnt mean to say, as a historical matter, were irrelevant. I meant to say the idea of a parser generator is a solution to a problem that that real world langs don't really have. When writing a programming language, your issue isnt how much time the parser is going to take to write, or how complex it's going to be. The parser is a relatively trivial part of the problem. Due to language…

The one thing parser generators do is that they ensure that the language you implement actually matches the grammar you wrote. That’s still an important assurance to have.

they also tell you where the grammar is ambiguous, which can be useful
Post reply on HN