Re: Baby X is bor nagain

On 27/06/2024 21:23, Tim Rentsch 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.

Which ones? I thought its C99 support was far more complete than mine.

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

People develop sofware using compilers like gcc, and will naturally do whatever it takes to make them work with that tool. They might inadvertently use extensions.
Probably not many test across multiple compilers, though some projects specifically check for compilers like GCC or MSVC and will use dedicated conditional blocks for each. I don't think I've seen such code for TCC.
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 think that it tries to be a drop-in replacement for gcc, so supports some of its options, even if they don't do anything. Like -O3.
Position-independent code seems to be a recent thing with gcc tools. My tools didn't support it either, until a year ago when I found out about ASLR.
For most, PIC isn't a necessity. But tcc supports shared libraries, and some kinds of relocation, if not full PIC, are necessary.

the tcc man page says.)  That project absolutely relies on -fPIC,
so if tcc doesn't support it that's a deal breaker.

tcc isn't perfect and there are missing bits especially with headers and libraries. Fixing that would make it a bit bigger, but not 100 times bigger. If more people took it seriously then it might get done. gcc has been under development since 1987.