Re: Baby X is bor nagain

bart <bc@freeuk.com> writes:

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.

I didn't post to have a conversation about tcc.  I just thought
people might be interested to hear about the trial.

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.

I routinely use -pedantic-errors for my compiles, and am totally
intolerant of any warning or error messages.  I very much doubt
my builds use any extensions.

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.

I would say tcc accepts the -fPIC option but does not support it.

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.

Support for -fPIC is a must-have for that project.  I'm not going
to spend time investigating possible partial solutions when I
already have other options available that are known to work.