tcc - first impression. Was: Baby X is bor nagain

On Thu, 27 Jun 2024 13:23:50 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

bart <bc@freeuk.com> writes:
 

On 26/06/2024 13:15, Ben Bacarisse wrote:
 

bart <bc@freeuk.com> writes:
 

On 25/06/2024 16:12, David Brown wrote: 

>
...
 

I /do/ use Python.  I use it when it is an appropriate language
to use, which is very different circumstances from when I use C
(or C++).  Different tools for different tasks. 

>
And yet neither of you are interested in answering my question,
which was why its simplistic bytecode compiler is acceptable in
this scenario, but would be considered useless if applied to C
code. 

>
You throw out a lot of these sorts of question, by which I mean
questions that you either /do/ know the answers to or which you
/should/ know the answers to.
>
If a software engineering student asked me this sort of "challenge"
question it would immediately become homework:  come up with at
least two scenarios in which a simplistic C bytecode compiler
would be an unacceptable tool to use, and two in which Python with
a trivial bytecode compiler would be an acceptable tool to use.
In each case explain why.  Anyone who could not would get marked
down on the course. 

>
I'm not sure what you're implying here.
>
Some here are consistently saying that any compiler whose internal
processes are not at the scale or depth that you find in
professional', 'industrial scale' products like gcc, clang, icc, is
not worth bothering with and is basically a useless toy. 

 
After reading the above I decided to try tcc.  I used tcc for
the first time earlier today.
 
First I tried using tcc for my most recent project.  That
didn't go anywhere, because that project relies on C11,
and tcc doesn't support C11.
 
Next I tried using tcc on a small part of my larger current
project.  That test involves compiling one .c file to produce a
.o file, and linking with several other .o files to produce an
executable, and running the executable.  The .c file being
compiled uses C99 and doesn't need C11.
 
The first thing that came up is tcc doesn't support all of
C99.  There are some C99 features that tcc just doesn't
understand.  In this case the infringements were minor so I
edited the source to work around the missing features.
 
The second thing to come up is some language incompatibilities.
There are language features that tcc understands, sort of,
but implements them in a way that didn't work with my source
code.  To be fair, a case could be made that what tcc does
conforms to the C standard.  However, the code I had before
works fine with gcc and clang, and doesn't with tcc.  Here
again the changes needed were minor so I edited the source
to work around the problem.
 
The third thing to come up was the link step.  Compiling the
one .c file with tcc -- and there are three other .o files
produced using gcc -- implicated the link step, which needed
to be done with tcc to avoid some undefined symbols.  That
kind of surprised me;  I'm used to being able to mix gcc
object files and clang object files with no difficulty,
so having the link step fail caught me off guard.
 
After taking care of all that the build did manage to produce an
executable, which appears to have run successfully.
 
After doing a trial run with the produced executable, I looked at
the tcc man page.  As best I can tell, tcc simply silently
ignores the -fPIC option.  (I didn't test that, I only read what
the tcc man page says.)  That project absolutely relies on -fPIC,
so if tcc doesn't support it that's a deal breaker.
 
Not offering any conclusion.  Just reporting my experience.

I tried tcc too.

1. It is easy to download. It does not need installation apart from
unzip.

2. It is very fast. Even when used from makefile, which is not an
optimal mode of use, in my tests more than 3 times faster than MSVC in
non-parallel build and more that twice faster in parallel build on
quad-core CPU. And that on project that spends unproportionally long
time in link. I am ready to believe that on more typical projects
(i.e. more compile time, less link time) the difference would be over
5x.
For the record, on this project 'gcc -O2' was ~1.7x slower than 'MSVC
-O2' and 'gcc -O0' was ~1.1x slower than 'MSVC -O2'; the later
difference probably because somewhat faster compilation by 'gcc -O0' was
outdone by much slower link.

3. Exe is slow, but not slower than gcc -O0. About the same. In this
particular test it meant ~2.5 times slower than optimized gcc or MSVC
binary.


4. In this particular project I encountered few inconvenient
incompatibilities:
4.1. no support for %zd and %zu. May be, Linux version is better in that
regard?
4.2. Code like below does not compile. I don't know whether it is legal
'C' or not,
but gcc, clang and MSVC compilers accept it o.k.
label:int bar;
4.3. c11/c17 things that are supported even by MSVC, which is generally
does not claim full C11 support:
_Alignof()

It's close to advertised, i.e. it is not C17, but has few features of
C17.