Re: Baby X is bor nagain

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.