Re: [Tinycc-devel] Fix signedness of LL shift operators in libtcc1.c (grischka-2005-09-25 case_10)

[David A. Wheeler]

Rob Landley:
> I is confuse-ed.
> What's the #define __TINYC__ for?  By which I mean why is there a codepath 
> that doesn't use it, and under what circumstances would it be naturally 
> enabled (or actually needed) rather than just forced for testing purposes?

It's for self-hosting.  That is, when tcc is completely hosting itself, without 
another compiler doing any of its work for it.

When you do a "make" of tcc, it normally compiles its internal library 
libtcc1.c using the local HOST library (e.g., gcc) - and NOT tcc.  Do a "make 
clean; make" and you'll see this:
gcc -O2 -Wall -c -o libtcc1.o libtcc1.c
Since other compilers (like gcc) will normally produce higher-performing 
results than tcc itself will, I think that is a reasonable default.

But tcc _CAN_ compile its own library libtcc1, so tcc can completely host 
itself. But self-hosting introduces a complication.  When you're compiling but 
using a different (host) compiler, there's no need to figure out how to 
implement shift operations for long long; just call the host compiler's 
implementation and be done with it.  But in the special case where tcc is 
self-hosting, its shift operations obviously can't call themselves for their 
own implementation.  Recursion is fine, but there has to be a way to end the 
recursion!

That's what the __TINYC__ option is for; it lets you say "I'm building a 
_self-hosting_ environment, so use THIS code to implement it."

> (Any time the checkin comment is 5 times the size of the patch, I worry. :)

Understand.  This particular patch only affects a "not default" case, which is 
why it takes extra time to explain.  But self-hosting is actually something I 
_WANT_, so I'm submitting the patch.

--- David A. Wheeler