[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] Fix signedness of LL shift operators in libtcc1.c (gr
David A. Wheeler
Re: [Tinycc-devel] Fix signedness of LL shift operators in libtcc1.c (grischka-2005-09-25 case_10)
Thu, 03 May 2007 17:50:07 -0400 (EDT)
> 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
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