
8cc: A Small C Compiler - adamnemecek
https://github.com/rui314/8cc
======
orangea
This is an interesting design decision:

> No memory management is a memory management scheme in 8cc. Memory regions
> allocated using malloc are never freed until the process terminates. That
> has greatly simplified the code and the APIs because 1) you can write code
> as if garbage collector were present, and 2) that design decision has
> eliminated use-after-free bugs entirely.

~~~
kgabis
Walter Bright did something similar in D's compiler
([http://www.drdobbs.com/cpp/increasing-compiler-speed-by-
over...](http://www.drdobbs.com/cpp/increasing-compiler-speed-by-
over-75/240158941))

>DMD does memory allocation in a bit of a sneaky way. Since compilers are
short-lived programs, and speed is of the essence, DMD just mallocs away, and
never frees. This eliminates the scaffolding and complexity of figuring out
who owns the memory and when it should be released. (It has the downside of
consuming all the resources of your machine if the module being compiled is
big enough.)

------
sanxiyn
If you like a hobby C compiler, check nwcc(Nils Weller's C Compiler) too.

[http://nwcc.sourceforge.net/](http://nwcc.sourceforge.net/)

nwcc is a bit more mature. It supports multiple architectures, multiple OSes,
and it can bootstrap GCC.

~~~
justincormack
pcc[1] is in a pretty good state, it can compile most of NetBSD, and is under
active development.

[1] [http://pcc.ludd.ltu.se/](http://pcc.ludd.ltu.se/)

~~~
swah
There is also [http://bellard.org/tcc/](http://bellard.org/tcc/)

~~~
ackalker
...which can compile a(n older, preprocessed, but none the less) Linux kernel
"on the fly", while booting:

[http://bellard.org/tcc/tccboot.html](http://bellard.org/tcc/tccboot.html)

~~~
swah
And Rob Landley wants to plug his fork of tcc into qemu code generator
[http://www.landley.net/qcc/](http://www.landley.net/qcc/) to do something
that I do not completely understand but sounds awesome!

------
SixSigma
I wish it had a different name. 8c is the name of the plan c compiler on x86

[http://man.cat-v.org/plan_9/1/2c](http://man.cat-v.org/plan_9/1/2c)

~~~
logicallee
where does the 8 come from? (that it occurred to both project creators.)

~~~
SixSigma
Maybe 8086. But the Plan9 ones have a number for each arch (until it was more
than 9!)

It was packaged as kencc for *nix, in honour of Ken

[http://gsoc.cat-v.org/projects/kencc/](http://gsoc.cat-v.org/projects/kencc/)

~~~
4ad
That kencc never worked right, this is the ken-cc to use now:
[https://code.google.com/p/ken-cc/](https://code.google.com/p/ken-cc/)

------
userbinator
Always good to see more relatively small C compilers, even if not in the
_extremely_ small size class.

That said, I get a feeling this one has many more files than necessary, as a
lot of them only have a few functions in them that could be consolidated into
one "utilities" file.

~~~
andrewchambers
This was written for readability.

~~~
ptaipale
I think having many small files is not good for readability.

It may be good for reading that one file, but not for understanding the whole.

~~~
vog
I believe this is mostly a matter of taste. I find this style very consistent.
Each file deals with exactly one abstract data type, and all functions around
it.

This is common in many languages. Java enforces one (public) class per file,
which is also a common coding style in C++, Python, Ruby and PHP, even though
those languages don't enforce that.

You also find this in more modern languages like OCaml, where it is
recommended to have one "module" per file, and one "module" concentrates on
one data type. (and maybe one or two helper types if needed, much like in-
class type definitions in C++)

This may be unusual in C projects, but it does have its merits. I read the
code and wonder "Oh, what exactly is that 'dict' stuff?". Then, I can blindly
guess the file names "dict.h" and "dict.h". I see a full explaination of
"dict" and nothing else. I then notice that it is a combination of "map" and
"vector", and maybe that's all I need to know. If not, I dig into "map.c" and
"vector.c".

Otherwise, I'd have to search, and finally find it in some unrelated file name
like "utils", "utililities" or "mapvectorutils". Then I have to search for all
dict-relevant code in that file, skipping through a bunch of unrelated code.

To get the "whole picture", I'd prefer to see a simple diagram (autogenerated
by IDE, or as part of the docs) that shows which module depends on which other
module, maybe somehow arranged into layers. The other strategy "group multiple
modules into a file" may convey the highest level quite well, but utterly
fails to explain the dependencies of the modules inside a single file.

~~~
barrkel
Your text search skills or tools are lacking, then. In an IDE, "go to
definition" solves this problem. In an editor, incremental text search over
the entire project solves this problem (I normally use helm-git-grep in
emacs).

I'm a fan of bigger and fewer files. Atomized bits of functionality are
tedious to read, when you have to read lots of code to understand the gestalt.

~~~
vog
_> Your text search skills or tools are lacking_

Ad Hominem should have to place at HN. Please don't do that.
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

~~~
barrkel
If you seriously need lots of tiny files in order to find code, it is a fact
that you don't know how to use the tools you have available.

That's my professional opinion.

~~~
vog
_> If you seriously need lots of tiny files in order to find code_

Nobody said that.

Please read more carefully, especially before goofing off others. Or, simply
don't goof off anyone in the first place.

------
xjia
If more people knew how to write compilers, is it likely that programming
languages will be better?

~~~
robzyb
Compilier design and programming language design are two very diffierent
things.

Perhaps someone could even make the argument that a programming language is
BEST designed by someone who doesn't know how to make a compiler?

The choices for a programming language should purely be based on the language,
and on the user experience. In the design phase no thought will be given to
compiler design (initially) and all of that will eventually be hiddden as
implementaiton details.

~~~
yoklov
Long compile times are bad user experience, and language design influences
this.

Performance is also extremely important for language ux, and there are
certainly constructs that will prevent your language from ever being
efficient. Someone completely unfamiliar with compiler design could easily add
these to the language on features that are simply not worth it, even in his or
her own eyes.

Besides, have you ever looked back on something and said 'Gee, I wish I knew
less about this when I started'

~~~
robzyb
I understand your point. Perhaps I went a bit too gung-ho with my POV.

I'd note, though, that long compile times shouldn't be too dependant on
language design, should it?

I feel that an argument could be made that if a programming language is well
defined, then a well written compiler could be well thought out and designed
around it.

Of course, I'm sure that there are counterpoints. I'm sure that there are
languages for which it is very difficult to write a "fast" compiled.

> Besides, have you ever looked back on something and said 'Gee, I wish I knew
> less about this when I started'

Actually, I kind of have. Experts (for lack of a better term) sometimes make
their solutions more complicated than they need to be, and this is partly
because they have the knowledge to do that.

~~~
userbinator
_Experts (for lack of a better term) sometimes make their solutions more
complicated than they need to be, and this is partly because they have the
knowledge to do that._

I think that's caused by a slightly different effect - not considering
essential and incidental complexity. It is true that for some programmers, the
urge to put in as many things as they know tends to override the more basic
goal of solving the problem in the most direct way.

------
101914
"x86_64 Linux only"

~~~
oscargrouch
I' ve compiled this in FreeBSD also.. no problem

Now it just need to parse the FreeBSD stdio.h correctly..

