Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Bart Newsgroups: comp.lang.c Subject: Re: else ladders practice Date: Sun, 24 Nov 2024 12:20:20 +0000 Organization: A noiseless patient Spider Lines: 112 Message-ID: References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sun, 24 Nov 2024 13:20:21 +0100 (CET) Injection-Info: dont-email.me; posting-host="ce2114238f6dc927920bdb19bad491fa"; logging-data="2355608"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+vb71yfPv/AtXDbrHlk5kY" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:tSPYrS58Lp0GBcVW7TPVnfhIUYM= Content-Language: en-GB In-Reply-To: Bytes: 5886 On 24/11/2024 05:03, Waldek Hebisch wrote: > Bart 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.)