Re: else ladders practice

On 24/11/2024 05:03, Waldek Hebisch wrote:

Bart <bc@freeuk.com> wrote:

gcc is just a lumbering giant, a 870MB installation, while tcc is 2.5MB.

 Yes, but exact size depends which version you install and how you
install it.  I installed version 6.5 and removed debugging info from
executables.  The result is 177MB, large but significantly smaller
than what you have.

Most of a gcc installation is hundreds of header and archive (.a) files for various libraries. There might be 32-bit and 64-bit versions. I understand that. But it also makes it hard to isolate the core compiler.
I might try copying the directory tree to a pen-drive, but if there was one essential file missing out of 1000s, I wouldn't know. Test-running it from the pen-drive wouldn't work as, on Windows, it will likely be picking up those files from the original installation.
In fact, it's quite hard to run two or more gcc versions on Windows, since they use the OS's list of search paths to look for support files (cc1.exe etc), rather than use a path relative to the location of the gcc.exe that was launched.
A single-file compiler doesn't have that problem, as there are no auxiliary files!

As for sizes:
>
   c:\c>dir hello.exe
   24/11/2024  00:44             2,048 hello.exe
>
   c:\c>dir a.exe
   24/11/2024  00:44            91,635 a.exe         (48K with -s)
>
(At least that's one good thing of gcc writing out that weird a.exe each
time; I can compare both exes!)

 AFAICS this is one-time Windows overhead + default layout rules for
the linker.  On Linux I get 15952 bytes by defauls, 14472 after
striping.  However, the actual code + data size is 1904 and even
in this most is crap needed to support extra features of C library.
 In other words, this is mostly irrelevant, as people who want to
get size down can link it with different options to get smaller
size down.  Actual hello world code size is 99 bytes when compiled
by gcc (default options) and 64 bytes by tcc.

I get a size of 3KB for tcc compiling hello.c under WSL.
On Windows, my cc compiler has the option of generating my private binary format called 'MX':
   c:\c>cc -mx hello
   Compiling hello.c to hello.mx
   c:\c>dir hello.mx
   24/11/2024  11:58               194 hello.mx
Then the size is 194 bytes (most of that is a big header and list of default DLL files to import). However that requires a one-off launcher (12KB compiled as C) to run it:
   c:\c>runmx hello
   Hello, World!
(In practice, MX files are bigger than equivalent EXEs since they contain more reloc info. I developed the format before I had options for PIC/relocatable code, which is necessary for OBJ/DLL formats.)

I know none of this will cut any ice; for various reasons you don't want
to use tcc.

 Well, I tried to use tcc when it first appeared.

Up until 0.9.26 it was quite poor. That was the time I started my C compiler project (2017). At one point, I had a program (a lexing benchmark), which ran slightly faster under my dynamic language interpreter, than using tcc-compiled native code!
This was because of its poor implementation of 'switch' which figured heavily in my test.
But later that year, 0.9.27 came out, which fixed such issues, and was a   much better, complete and conforming C compiler all round than my product.

There is question of trust: when what I reported remained unfixed
I lost faith in quality of tcc.  I still need to check if it is
fixed now, but at least now tcc seem to have some developement.
 

One of them being that your build process involves N slow stages so
speeding up just one makes little difference.

 Yes.
 

This however is very similar to my argument about optimisation; a
running app consists of lots of parts which take up execution time, not
all of which can be speeded up by a factor of 9. The net benefit will be
a lot less, just like your reduced build time.

 If I do not have good reasons to write program in C, then likely I
will write it in some higher-level language.  One good reason
to use C is to code performance-critical routines.

It can also do manipulations that are harder in a 'softer', safer HLL. (My scripting language however can still do most of those underhand things.)