Re: Baby X is bor nagain

On 27/06/2024 20:51, David Brown wrote:

On 27/06/2024 18:28, bart wrote:

On 27/06/2024 13:31, David Brown wrote:

On 27/06/2024 13:16, bart wrote:

>

 I'm snipping a lot, because answering it will not get us anywhere except more frustrated.
 

>
I do dislike brace-syntax, 0-based indexing, and case-sensitivity. Those are common characteristics.
>

 I can fully appreciate preferences and opinions - likes and dislikes. It's the continued determination to fight things that is irrational and incomprehensible.  I happen to like these three things.  But if I am programming in Python (with indentation rather than braces), Lua (with 1-based indexing) or Pascal (case insensitive), I shrug my shoulders and carry on.  I don't go to comp.lang.python, or comp.lang.lua and rant and rave about how terrible the language is and how my own tools are vastly better than anything else.
 

>

Like most developers, I try to use the best tool for the job

>
Sure, you're a user, you don't get involved in devising new languages or creating tools, you have to use existed, trusted products. But you let that get in the way of your views with a low tolerance for anything different or that seems amateurish or pointless.

 That makes /no/ sense at all.
 First, I am as capable as you or anyone else at finding things in C or any other language that I think are not as good as they could have been, or poor design decisions.  The fact that I am a user, not an implementer, is irrelevant - programming languages are made for the users, and the effort needed to implement them is of minor concern.
 

>
Over a decade ago I started looking at whole-program compilers which, if I was more into optimising, would be lend themselves easily to whole-program optimisation.
>
But while you will dismiss my own efforts out of hand, you do at least appreciate the benefits of 'LTO' (which I consider a third rate version of what I do, and considerably more complex).

 To be clear - as I have stated /many/ times, I appreciate the effort needed to make your tools, and the achievement of making them.  What I dispute is your insistence that your tools are /better/ than mainstream tools.
 

>

I have no "irrational hatred" of tcc - it is simply incapable (in a great many ways) of doing the job I need from a compiler, and for the jobs it /can/ do it is in no way better than the tools I already need and have.

>
>
This is what I mean about you being incapable of being objective. You dissed the whole idea of tcc for everyone. Whereas what you mean is that it wouldn't benefit /you/ at all.

 Much of what I say is clearly marked as being about /my/ uses.  But yes, I sometimes say that things that I believe apply to most people.  I've yet to hear of anything, from you or anyone else, to change my thoughts on these things.
 

>
I can understand that: if you have a dozen slow components of some elaborate process, replacing one with a faster one would make little difference.
>
My view is different: I already have /half/ a dozen /fast/ components, then replacing just one with a slow product like 'gcc' makes a very noticeable difference.
>

 No one doubts that gcc is slower than tcc.  That is primarily because it does vastly more, and is a vastly more useful tool.  And for most C compiles, gcc (even gcc -O2) is more than fast enough.

And for most of /my/ compiles, the code produced by gcc-O0 is fast enough. It also about the same speed as code produced by one of my compilers.
So I tend to use it when I want the extra speed, or other compilers don't work, or when a particular app only builds with that compiler.
Otherwise the extra overheads are not worth the bother.

And it is free, and easily available on common systems.  Therefore there is no benefit to using tcc except in very niche cases.

And my argument would be the opposite. The use of gcc would be the exception. (Long before I used gcc or tcc, I used lccwin32.)
Here's the result of an experiment I did. gcc 14 is about 800MB and over 10,000 files. I wanted to see the minimal set of files that would compile one of my generated C files.
After half an hour I reduced the files to the following 15, to compile to object code only (the link dependencies were too complex):
-----------------------
Directory of C:\tdm\bin
09/06/2024  23:13         1,837,582 as.exe
09/06/2024  23:13         1,924,622 gcc.exe
09/06/2024  23:13             4,627 gdb-add-index
09/06/2024  23:13           930,493 libgcc_s_seh-1.dll
09/06/2024  23:13           499,289 libgmp-10.dll
09/06/2024  23:13         1,679,127 libiconv-2.dll
09/06/2024  23:13           344,105 libintl-8.dll
09/06/2024  23:13         2,252,996 libisl-23.dll
09/06/2024  23:13           136,406 libmpc-3.dll
09/06/2024  23:13           676,258 libmpfr-6.dll
09/06/2024  23:13            94,355 libwinpthread-1.dll
09/06/2024  23:13           996,878 libzstd.dll
09/06/2024  23:13           121,870 zlib1.dll
Directory of C:\tdm\libexec\gcc\x86_64-w64-mingw32\14.1.0
09/06/2024  23:15        34,221,582 cc1.exe
               15 File(s)     45,720,190 bytes
------------------------
(There are no header files; my generated C doesn't use them. Note this is not 'tdm' despite the name. The gdb file probably isn't needed, I hadn't spotted it.)
The equivalent set for tcc would be 2 files, totalling 0.22MB, about 1/200th the size - and it produces EXEs!
I can't explain to somebody who doesn't get it why a small, simple tool is desirable.