On Wed, 12 Mar 2025 00:43:51 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wrote:

On Wed, 12 Mar 2025 00:58:43 +0200, Michael S wrote:

BTW, I think that tcc is doing damage to itself by refusal to
support ucrt variant of Microsoft's C RTL.

Damaging their market share and hurting their revenues?

I don't know what exactly motivates people to continue to maintain tcc
after all fun things, like, for example, writing working compiler*, are
done years ago. But it seems that extending user base and increasing satisfaction of existing users is not totally unimportant for this
people.

--------
* - writing compiler is not my personal idea of fun, but I am pretty
sure that it was considered fun by original tcc developers

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/03/2025 08:53, Michael S wrote:

On Wed, 12 Mar 2025 00:43:51 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wrote:

On Wed, 12 Mar 2025 00:58:43 +0200, Michael S wrote:

BTW, I think that tcc is doing damage to itself by refusal to
support ucrt variant of Microsoft's C RTL.

Damaging their market share and hurting their revenues?

I don't know what exactly motivates people to continue to maintain tcc
after all fun things, like, for example, writing working compiler*, are
done years ago. But it seems that extending user base and increasing satisfaction of existing users is not totally unimportant for this
people.

Tcc is a more important product than you might think. It is a compact
program of 200-300KB that can turn C source code into binary.

It's looked down upon by most people here. But if you've implemented a
language that generates intermediate C for example, then it will depend
on a C compiler to complete the process.

Tcc provides simple solution with a small footprint, that is also very,
very fast. A backend solution like gcc will be at least 50MB is you
strip all the necessary stuff (some 0.7GB typically), or well north of
100MB with Clang.

They will also be 20-30 times slower even to generate the same code
quality. Tcc's code is not great but it's certainly interpreter-speed
either, which is another backend option.

Another backend possibility is LLVM, but is vastly more complex, and
just as slow.

Note that for this kind of application, the input C source should
already be verified by the front-end compiler. No deep analysis is
needed. If there are C compiler errors, it will be a fault in the front-end.

c:\cx>tim gcc lua.c
Time: 3.359

c:\cx>tim tcc lua.c
Time: 0.130

--------
* - writing compiler is not my personal idea of fun, but I am pretty
sure that it was considered fun by original tcc developers

I think the original was meant to be very small, like 2000 lines or
something.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 12 Mar 2025 14:04:16 +0000
bart <[email protected]> wrote:

On 12/03/2025 08:53, Michael S wrote:

On Wed, 12 Mar 2025 00:43:51 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wrote:

On Wed, 12 Mar 2025 00:58:43 +0200, Michael S wrote:

BTW, I think that tcc is doing damage to itself by refusal to
support ucrt variant of Microsoft's C RTL.

Damaging their market share and hurting their revenues?

I don't know what exactly motivates people to continue to maintain
tcc after all fun things, like, for example, writing working
compiler*, are done years ago. But it seems that extending user
base and increasing satisfaction of existing users is not totally unimportant for this people.

Tcc is a more important product than you might think. It is a compact
program of 200-300KB that can turn C source code into binary.

You post does not answer the question in hand, which is "What motivates
current tcc maintainers to go on?"
Nor does it help us to decide whether support for UCRT-based C RTL is
would be worth their effort (my original suggestion) or pointless, as
suggested by Lawrence D'Oliveiro.

As to your advocacy, I am not a good target. I already evaluated tcc,
already was impressed by its compilation speed, already admitted that it
ca be useful in scenario where C is used as intermediate language,
already suggested a killer app (compiled HDL simulators), was already disappointed by implementation the most sexy of its features (bound
checking) and already decided that personally I have no use for tcc.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/03/2025 14:32, Michael S wrote:

On Wed, 12 Mar 2025 14:04:16 +0000
bart <[email protected]> wrote:

On 12/03/2025 08:53, Michael S wrote:

On Wed, 12 Mar 2025 00:43:51 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wrote:

On Wed, 12 Mar 2025 00:58:43 +0200, Michael S wrote:

BTW, I think that tcc is doing damage to itself by refusal to
support ucrt variant of Microsoft's C RTL.

Damaging their market share and hurting their revenues?

I don't know what exactly motivates people to continue to maintain
tcc after all fun things, like, for example, writing working
compiler*, are done years ago. But it seems that extending user
base and increasing satisfaction of existing users is not totally
unimportant for this people.

Tcc is a more important product than you might think. It is a compact
program of 200-300KB that can turn C source code into binary.

You post does not answer the question in hand, which is "What motivates current tcc maintainers to go on?"

I thought I did. It seems a reasonably well-known compiler with some interesting use-cases where a big product may be unsuited.

I'm sure there are enough users world-wide for it to be worth
maintaining, and people willing to do that.

There are also plenty of people interested in messing with compilers or
who want to contribute to such projects. Tcc's compiler comprises some
36 .c and .h files; gcc is more like 85,000 files.

So Tcc would be simpler to work with, given 99.95% fewer files, and to
make a noticeable difference to!

Nor does it help us to decide whether support for UCRT-based C RTL is
would be worth their effort (my original suggestion) or pointless, as suggested by Lawrence D'Oliveiro.

I don't know what the significance of UCRT-based means. As such that
would't make me stop using it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 12 Mar 2025 16:52:24 +0000
bart <[email protected]> wrote:

I don't know what the significance of UCRT-based means. As such that
would't make me stop using it.

UCRT would give them pretty good compliance with requirements of C99,
C11 and C17 standards. Not perfect, but a lot better that circa-2014
libraries that they are using today.
Also, I suppose that it will give better compatibility with MS tools. Personally for you, it likely means that GMP DLLs that I suggested
would work. And these DLLs are smaller, better tested and hopefully
compiled from newer sources than non-UCRT variant that you found.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bart <[email protected]> writes:

On 12/03/2025 14:32, Michael S wrote:

On Wed, 12 Mar 2025 14:04:16 +0000
bart <[email protected]> wrote:

On 12/03/2025 08:53, Michael S wrote:

On Wed, 12 Mar 2025 00:43:51 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wrote:

On Wed, 12 Mar 2025 00:58:43 +0200, Michael S wrote:

BTW, I think that tcc is doing damage to itself by refusal to
support ucrt variant of Microsoft's C RTL.

Damaging their market share and hurting their revenues?

I don't know what exactly motivates people to continue to maintain
tcc after all fun things, like, for example, writing working
compiler*, are done years ago. But it seems that extending user
base and increasing satisfaction of existing users is not totally
unimportant for this people.

Tcc is a more important product than you might think. It is a compact
program of 200-300KB that can turn C source code into binary.

You post does not answer the question in hand, which is "What motivates
current tcc maintainers to go on?"

I thought I did. It seems a reasonably well-known compiler with some >interesting use-cases where a big product may be unsuited.

I would quibble about the "well-known" part. I'd never heard
of it before you first mentioned it in this newsgroup.
(and I've used dozens of open source and proprietary C compilers
over the last four decades).

It's clearly not usable for most of my projects where
performance of the compiled code is paramount.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 12 Mar 2025 16:52:24 +0000
bart <[email protected]> wrote:

On 12/03/2025 14:32, Michael S wrote:

On Wed, 12 Mar 2025 14:04:16 +0000
bart <[email protected]> wrote:

On 12/03/2025 08:53, Michael S wrote:

On Wed, 12 Mar 2025 00:43:51 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wrote:

On Wed, 12 Mar 2025 00:58:43 +0200, Michael S wrote:

BTW, I think that tcc is doing damage to itself by refusal to
support ucrt variant of Microsoft's C RTL.

Damaging their market share and hurting their revenues?

I don't know what exactly motivates people to continue to maintain
tcc after all fun things, like, for example, writing working
compiler*, are done years ago. But it seems that extending user
base and increasing satisfaction of existing users is not totally
unimportant for this people.

Tcc is a more important product than you might think. It is a
compact program of 200-300KB that can turn C source code into
binary.

You post does not answer the question in hand, which is "What
motivates current tcc maintainers to go on?"

I thought I did. It seems a reasonably well-known compiler with some interesting use-cases where a big product may be unsuited.

I'm sure there are enough users world-wide for it to be worth
maintaining, and people willing to do that.

That answer why maintaining tcc is a good thing for community. It does
not answer why it is good for maintainers.

There are also plenty of people interested in messing with compilers
or who want to contribute to such projects. Tcc's compiler comprises
some 36 .c and .h files; gcc is more like 85,000 files.

So Tcc would be simpler to work with, given 99.95% fewer files, and
to make a noticeable difference to!

It is unlikely that existence of such tweakers makes life of
responsible maintainers any easier. The opposite is more likely.
Now, it is possible that harder life is what they seek.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/03/2025 18:14, Michael S wrote:

On Wed, 12 Mar 2025 16:52:24 +0000
bart <[email protected]> wrote:

I don't know what the significance of UCRT-based means. As such that
would't make me stop using it.

UCRT would give them pretty good compliance with requirements of C99,
C11 and C17 standards. Not perfect, but a lot better that circa-2014 libraries that they are using today.
Also, I suppose that it will give better compatibility with MS tools. Personally for you, it likely means that GMP DLLs that I suggested
would work. And these DLLs are smaller, better tested and hopefully
compiled from newer sources than non-UCRT variant that you found.

The failures I had on some GMP DLLS manifested with both gcc and tcc
compilers.

In any case, the GMP DLL will have its own set of dynamic imports
(static imports will be part of its code). The failing one imported
these dynamic libraries:

Name: VCRUNTIME140.dll
Name: api-ms-win-crt-runtime-l1-1-0.dll
Name: api-ms-win-crt-stdio-l1-1-0.dll
Name: api-ms-win-crt-string-l1-1-0.dll
Name: api-ms-win-crt-locale-l1-1-0.dll
Name: api-ms-win-crt-heap-l1-1-0.dll
Name: api-ms-win-crt-convert-l1-1-0.dll
Name: KERNEL32.dll

And the working one (gcc/tcc) imported these:

Name: KERNEL32.dll
Name: api-ms-win-crt-convert-l1-1-0.dll
Name: api-ms-win-crt-environment-l1-1-0.dll
Name: api-ms-win-crt-filesystem-l1-1-0.dll
Name: api-ms-win-crt-heap-l1-1-0.dll
Name: api-ms-win-crt-locale-l1-1-0.dll
Name: api-ms-win-crt-private-l1-1-0.dll
Name: api-ms-win-crt-runtime-l1-1-0.dll
Name: api-ms-win-crt-stdio-l1-1-0.dll
Name: api-ms-win-crt-string-l1-1-0.dll
Name: api-ms-win-crt-time-l1-1-0.dll
Name: api-ms-win-crt-utility-l1-1-0.dll

So nothing to do with tcc.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-03-12, Michael S <[email protected]> wrote:

On Wed, 12 Mar 2025 16:52:24 +0000
bart <[email protected]> wrote:

I don't know what the significance of UCRT-based means. As such that
would't make me stop using it.

UCRT would give them pretty good compliance with requirements of C99,
C11 and C17 standards. Not perfect, but a lot better that circa-2014 libraries that they are using today.

What are the using for basic C library functions? MSVCRT.DLL?

Maybe the tcc project has simply not been informed about the
emergence of the UCRT.

The UCRT is mainly of interest to people who care about the issue that
using the MSVCRT.DLL is not documented or recommended by Microsoft.

UCRT is like a MSVCRT that is sanitized, modernized and documented for application use.

There are disadvantages to the UCRT. I think it's not available on
systems older than around Windows 7?

Windows 10 started packaging UCRT with the system, but I think
not from the beginning; it's possible that there are installations
of Windows 10 that have not been updated, which don't have it.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @[email protected]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 12 Mar 2025 14:04:16 +0000, bart wrote:

Another backend possibility is LLVM, but is vastly more complex, and
just as slow.

There are lighter-weight alternatives <https://c9x.me/compile/>.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/03/2025 02:36, Lawrence D'Oliveiro wrote:

On Wed, 12 Mar 2025 14:04:16 +0000, bart wrote:

Another backend possibility is LLVM, but is vastly more complex, and
just as slow.

There are lighter-weight alternatives <https://c9x.me/compile/>.

I found it limiting:

* It only works on Linux
* The input (intermediate language or IL) has to be textual SSA format
* The output is AT&T assembly...
* ...which has to be assembled with 'as'...
* ...which has to be linked with 'ld'
* Input and output files need to be piped (?)

When I tested it on bigger inputs (my whole-program tools would produce
larg monolithic files) it also got quite slow.

If you compare with my own backend, if built into a standalone program:

* It is 40% the size of QBE (for a version targetting Win64 ABI)
* The input is simpler stack-based code with no SSA requirements
* The input can be either textual IL or via an API
* It can directly create binary executables with no external tools
* It can translate large inputs at millions of intructions per second
* It can optionally directly /execute/ programs in memory
* It can optionally /interpret/ the IL

Normally it's directly incorporated into my two main compilers and is
used via it's API.

So lightweight, small-footprint alternatives are quite viable.

Mine is a personal product, but if comparing instead to Tiny C:

* It can be smaller than QBE for an MVP (tcc.exe + headers + lib,
but when I tried it as backend, no headers were needed)
* The input is standard C code that everyone knows
* The output, like mine, is an executable binary
* It can process input at up to 1M lines per second
* It can also run the input directly in memory

The only downside is its poorer code (mine is somewhat better than tcc's
and seems to match QBE on the few benchmarks I tried).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 13 Mar 2025 12:08:42 +0000, bart wrote:

* It only works on Linux

At least it’s not restricted to x86 code: it does ARM and RISC-V (both 64- bit) as well.

But it’s only a code generator, and code generators shouldn’t be relying
on any advanced OS features like namespaces or event loops or like that;
it should be a piece of cake for somebody with your Windows development
skills to port it ... shouldn’t it?

If you compare with my own backend, if built into a standalone program:

Does yours handle any other target architecture besides x86?

* The input is simpler stack-based code with no SSA requirements

How efficient is the generated code, by comparison?

The only downside is its poorer code (mine is somewhat better than
tcc's and seems to match QBE on the few benchmarks I tried).

Any fool^H^H^H^Hcompiler class undergraduate can output stack-based code.
And a lot of them do.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/03/2025 22:02, Lawrence D'Oliveiro wrote:

On Thu, 13 Mar 2025 12:08:42 +0000, bart wrote:

* It only works on Linux

At least it’s not restricted to x86 code: it does ARM and RISC-V (both 64- bit) as well.

But it’s only a code generator,

Actually the project is simple enough to build on Windows (and is
considerably smaller if not using the makefile).

But the x64 output produced won't run on Windows.

and code generators shouldn’t be relying
on any advanced OS features like namespaces or event loops or like that;
it should be a piece of cake for somebody with your Windows development skills to port it ... shouldn’t it?

If you compare with my own backend, if built into a standalone program:

Does yours handle any other target architecture besides x86?

It handles x64 for Win64 ABI, and could be adapted or x64 SYS ABI, but I
don't have enough motivation for that (and little reason).

If other people were involved, then they could write a backend for my IL
for their target of choice, since part of it is finding a tidy and
simple IL to work with.

* The input is simpler stack-based code with no SSA requirements

How efficient is the generated code, by comparison?

I don't have enough examples of SSA programs to judge.

From the tests I did manage, they were about the same in performance
(but comparing on WSL vs on Windows).

Maybe you know of a real compiler that can produce suitable inputs for QBE?

The only downside is its poorer code (mine is somewhat better than
tcc's and seems to match QBE on the few benchmarks I tried).

Any fool^H^H^H^Hcompiler class undergraduate can output stack-based code.
And a lot of them do.

The stack code applies to the IL. The generated x64 code is register
based. But if it's all so easy, there should be plenty of such projects
about. There aren't.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bart <[email protected]> wrote:

Actually the project is simple enough to build on Windows (and is considerably smaller if not using the makefile).

I sometimes see a "Windows build" mentioned in TinyCC's mailing list.

gmane.comp.compilers.tinycc.devel

--
I do not bite, I just want to play.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)