
Obfuscated Tiny C Compiler (2002) - sndean
https://bellard.org/otcc/
======
saagarjha
Also see the Tiny C Compiler, which was born out of this project and now is a
pretty-full featured C compiler in its own right:
[https://bellard.org/tcc/](https://bellard.org/tcc/). It has a couple pretty
interesting features by virtue of its small size, such as being able to
"interpret" C code as well as generating executables in-memory so they're
portable across platforms without a lot of work.

~~~
mpweiher
And it is _fast_. I clocked it at over 200K lines/sec. Swift, on a typical
project, will do around 20. Not K, just lines/sec.

Of course the C code was a lot simpler, but still...

~~~
fdej
Wait, what? 50 milliseconds per line of code? How is that even possible?

~~~
mpweiher
Makes you wonder, right?

Of course, there are (still) pathological cases where a single line of code
will abort because it runs out of time.

    
    
       > cat too-complex.swift
       let a:[Int] = [1] + [2] + [3] + [4] + [5] + [6] + [7]
    

For me, this aborts after about a minute and a half:

    
    
       > time swiftc too-complex.swift 
       too-complex.swift:1:49: error: expression was too complex to be solved in reasonable time; consider breaking up the expression into distinct sub-expressions
       let a:[Int] = [1] + [2] + [3] + [4] + [5] + [6] + [7]
                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
    
       real	1m35.094s
       user	1m16.698s
       sys	0m5.141s
    
    

That appears to be some sort of exponential in type inference. Other similar
ones have been fixed.

The ternary expressions mentioned elsewhere also appear to be problematic, and
in general, there's little time bombs all over just waiting to go off.

The rate I mentioned earlier was taken from a CocoaHeads talk by someone who
built a caching mechanism for Carthage, because their Swift framework(s) of
around 20KLOC were taking ages to compile.

So it's a real-world example, not something made up.

~~~
munificent
_> That appears to be some sort of exponential in type inference._

If I recall, it's in the implicit conversions, not strictly the type
inference.

------
Ecco
Every other month an amazing project from Fabrice Bellard comes back under the
spotlight on HN. I guess you could train a ML model on previous posts and make
a automatic karma-generating machine :-)

~~~
saagarjha
He's such a prolific author that sooner or later you just get accustomed to
seeing another project on Hacker News and finding out that he wrote it.

------
ENTP
Quite literally the only "FB" on the internet worth bothering with. The guy is
a genius.

------
yiyus
After having spent some of my free time lately studying the b interpreter by
Arthur Whitney ([http://www.kparc.com/b/b.c](http://www.kparc.com/b/b.c)),
this looks quite straightforward to me.

That said, it is indeed tiny. Very nice project, as usual from FB.

~~~
exikyut
You'll need to click through to the parent comments for this to properly make
sense, but this is the most relevant bit of a subthread I think you may find
interesting:
[https://news.ycombinator.com/item?id=16368271](https://news.ycombinator.com/item?id=16368271)

~~~
yiyus
Thank you. I have already found a few interesting threads, mostly with
contributions from geocar, who seems to be working in kos. However, I have the
impression everything is kept quite secret around this, and I respect that.

My current interest in studying this code is more the journey than the result,
but I am quite sure I will have to try to approach someone more familiar with
the code at some point.

~~~
exikyut
I too have a journey-focused interest in studying the code, heh. I must admit
I'm mildly sad about the secrecy (and requirement to participate, presumably
to deter lurkers with indeterminable motives), but I suspect it's mostly
because K itself is used in finance (eg,
[http://archive.vector.org.uk/art10501320](http://archive.vector.org.uk/art10501320),
^F "brightly", end of that paragraph and all of the next small one), and it's
reasonable to consider that if it doesn't cost a lot of money that'll
categorically impact its relevancy :)

I guess this is also why Kona is generally regarded dismally - I wonder if
that view isn't carefully cultured/spread for similar reasons. In any case the
implementation is heavily tied to the success (which is interesting in and of
itself), which also ties the implementation to the niche, and I guess I lament
the impact the language's resulting general accessibility and reach because
things won't be changing anytime soon. Eh, I guess the
selfish(?)/survivalist(?) view is to clear the calendar and say hi while
Whitney's still teaching :P (I've been meaning to do exactly this, but my, er,
_calendar_ (life, really) doesn't permit me the confidence to say I'd
definitely be able to keep up.)

In the video it's mentioned there's not much optimization in kos. That's
mildly encouraging, from a general systems perspective and also from an
architectural standpoint (eg, functional programming can be
interesting/novel/weirdly-aesthetic _and_ "efficient enough" (or even more
than) with eg UI latency).

------
swah
Is there ane big reason why TCC is so fast - other than, of course, doing less
work that GCC ?

~~~
zde
Single pass compiler with back-patching. No intermediate code representation,
very simple optimizer (just constant folding and dead code removal). C
Preprocessor integrated with parser code. Back-end generates instruction
opcodes instead of assembly, eliminating another stage.

------
userbinator
These may possibly inspired by OTCC:

[https://news.ycombinator.com/item?id=8558822](https://news.ycombinator.com/item?id=8558822)

[https://news.ycombinator.com/item?id=8746054](https://news.ycombinator.com/item?id=8746054)

They're quite a bit larger, but not "obfuscated" (although still terse), so
could be more suitable to learn from.

