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

9cc: A Small C Compiler

github.com

Post reply on HN
Print view View original

31–40 of 70 posts

Re: 9cc: A Small C Compiler

#31

Post by nickpsecurity »

aidenn0 wrote: post #2

It lists a goal as "compiling real-world programs such as the linux kernel" The last time I investigated the linux kernel had so many gcc-isms that it was probably true that if you could compile the linux kernel, you could probably compile any program targeted to gcc.

xv6 might be nicer start:

https://pdos.csail.mit.edu/6.828/2012/xv6.html

For bootstrapping, the overall consensus is you make enough C to compile, without optimizations, early version of GCC which compiles itself from there until you reach current version. Several folks are trying to compile TCC instead to leverage it and dwheeler's work.

Re: 9cc: A Small C Compiler

#32

Post by [deleted] »

rui314 wrote: post #29
kazinator wrote: post #4

Small nitpick. Functions in C that take no arguments are written name(void){...} not name(){...}. This latter form is an old-style definition which doesn't introduce a prototype into the scope. For functions that have prototypes, it is okay, but when they do not, you're losing type checking (yes, even on the number of arguments). The following program compiles with no diagnostics for me with -W -Wall -ansi -pedantic,…

Quote from 6.7.6.3.14 of the C++11 spec ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf ): > An identifier list declares only the identifiers of the parameters of the function. An empty list in a function declarator that is part of a definition of that function specifies that the function has no parameters. The empty list in a function declarator that is not part of a definition of that function specifies…

[deleted]

Re: 9cc: A Small C Compiler

#33

Post by mmirate »

akkartik wrote: post #15

https://github.com/rui314/9cc/blob/882e4b2dd8/main.c#L7 int main(int argc, char **argv) { ... Vector *tokens = tokenize(path, true); Program *prog = parse(tokens); sema(prog); gen_ir(prog); if (dump_ir1) dump_ir(prog->funcs); optimize(prog); liveness(prog); alloc_regs(prog); if (dump_ir2) dump_ir(prog->funcs); gen_x86(prog); return 0; } This is wonderful.

And also wonderfully devoid of error-handling, too. It's the most common way for beautiful-looking C code to look beautiful.

Re: 9cc: A Small C Compiler

#34

Post by kazinator »

rui314 wrote: post #29
kazinator wrote: post #4

Small nitpick. Functions in C that take no arguments are written name(void){...} not name(){...}. This latter form is an old-style definition which doesn't introduce a prototype into the scope. For functions that have prototypes, it is okay, but when they do not, you're losing type checking (yes, even on the number of arguments). The following program compiles with no diagnostics for me with -W -Wall -ansi -pedantic,…

Quote from 6.7.6.3.14 of the C++11 spec ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf ): > An identifier list declares only the identifiers of the parameters of the function. An empty list in a function declarator that is part of a definition of that function specifies that the function has no parameters. The empty list in a function declarator that is not part of a definition of that function specifies…

That is of course the C11 (draft) spec, not C++.

Interesting find there. The wording is also in the C99 draft; it is not new.

It is in fact saying that the empty list in a definition is a special case and does declare that the function takes no parameters. To "specify" here can be understood to mean as inserting information about type into the declaration scope; that which a declaration does.

So that's a bit of a bug in GCC there; it should be treating this the same as (void) and therefore diagnosing that way. If not by default, then at least when -pedantic is applied. But nope:

   $ gcc -Wall -W -std=c11 -pedantic proto.c
   $

Re: 9cc: A Small C Compiler

#36

Post by catpolice »

marktangotango wrote: post #27
userbinator wrote: post #26

Earlier quoted context omitted.

Here is the discussion of the original Trusting Trust attack: https://news.ycombinator.com/item?id=13569275

Thanks I was referring to precedence climbing parser part of GP reply.

https://eli.thegreenplace.net/2012/08/02/parsing-expressions...

Precedence climbing is also (intimately) related to Pratt parsing, and there's a useful series of articles about the two here: https://www.oilshell.org/blog/2017/03/31.html

Re: 9cc: A Small C Compiler

#38

Post by userbinator »

marktangotango wrote: post #27
userbinator wrote: post #26

Earlier quoted context omitted.

Here is the discussion of the original Trusting Trust attack: https://news.ycombinator.com/item?id=13569275

Thanks I was referring to precedence climbing parser part of GP reply.

https://www.engr.mun.ca/~theo/Misc/exp_parsing.htm#climbing

Re: 9cc: A Small C Compiler

#39

Post by tptacek »

sifoobar wrote: post #13
cperciva wrote: post #10

Earlier quoted context omitted.

> Memory management is important even for short-lived programs. It would bring burden to the OS if you invoke this kind of "short-lived, memory-management-free" programs multiple times. All the memory is freed when the process exits. Why does it matter if you run the program multiple times?

It will put more pressure on the allocator when running, doing that a lot will likely have some kind of cumulative consequence down the line. I know from experience [0] that even reusing allocated memory rather than bouncing it back to malloc can have dramatic effects. [0] https://gitlab.com/sifoo/snigl/blob/master/src/snigl/pool.h

Wait, doesn't it do the opposite? The big thing that "pressures" an allocator is fragmentation, which you don't get at all if you never free.

Re: 9cc: A Small C Compiler

#40

Post by tptacek »

mshockwave wrote: post #9

>no memory management is the memory management policy in 9cc. We allocate memory using malloc() but never call free(). >I know that people find the policy odd, but this is actually a reasonable design choice for short-lived programs such as compilers. I'm strongly disagree at this point. Memory management is important even for short-lived programs. It would bring burden to the OS if you invoke this kind of "short-liv…

I think you're reacting more to the words that the author chose than the actual design decision, which is simply an instance of arena allocation.
Post reply on HN