tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Calling for Release 0.10.0


From: Domingo Alvarez Duarte
Subject: Re: [Tinycc-devel] Calling for Release 0.10.0
Date: Wed, 31 May 2023 16:02:26 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0

Hello all !

I would like to offer my patch for fully reentrant TCC for the upcoming release (see here https://github.com/mingodad/tinycc ) !

Cheers !

On 31/5/23 15:07, John Mastronardo via Tinycc-devel wrote:

David Koch is spot on. I couldn’t agree more, and I’m paraphrasing him here:

Pause the adventurous code. Do a feature freeze and a comparison checklist with other compilers. Then thoroughly test a few release candidates with a chosen set of popular platforms. After that, publish a completely stable new official TCC 10.0 that we can be proud of.

Like David, I’d like TCC to be treated more professionally than its original legacy.

And, I also thank you all for putting your time and passion into its maintenance.

—JM



On May 29, 2023, at 6:06 PM, david.koch@libertysurf.fr wrote:

Hi Detlef,

I don't care about the "simplicity" of tcc and its supposed goal not to compete with larger and more established compilers like gcc or clang.

Tcc still have to be reliable and not falling on simple corner cases because someone decided to push a patch on the mob branch, requiring someone else to remove it.

I'd like tcc not to be considered just a "quick hack" or a "toy compiler" due to its inherent simplicity, it still have to produce correct and reliable code.

Especially since its internals are so "simple", there is no reason tcc couldn't be thoroughly tested and stabilized orthogonally across all supported architectures.

It's been more than 5 years since the last "stable" release, I'd like the next one to be as much "reliable" despite the mob branch will still remain the Wild Wide West of salvage patches.

Experimenting is one thing, but regarding the last few months of adventurous code modifications and group discussions, I would NOT bet on just numbering the current state as being the new 0.10.0.

Let's do a feature freeze first, a comparison checklist with other compilers, supporting common flags and attributes, producing correct binary files (Windows, Linux, Mac, ...).

Then after a few release candidates, maybe only we could decide the last RC to be worthwhile enough to get released with the new official 0.10.0 tags that we could feel proud of.

Until then tcc:mob will just remain a nerd's joke and a geek's playground that only a few insiders can really use it after great hacking to get it to work almost like expected.

Our view on tcc may diverge, but rest assured I like it anyway, I just would like it to be treated more fairly and professionally than its original legacy.

Thank you all for putting all such time and passion into its maintenance.

Regards.


----- Mail d'origine -----
De: wine dev <wine.dev@web.de>
À: tinycc-devel@nongnu.org
Envoyé: Mon, 29 May 2023 14:39:17 +0200 (CEST)
Objet: Re: [Tinycc-devel]  Re :  Calling for Release 0.10.0

[Tinycc-devel] Re :  Calling for Release 0.10.0 – Hi,

the mob branch is pretty much unstable.

Before turning the mob branch into a new release, better do some thorough
checking and regression testing.

And have something consistent across the various supported platforms (x86,
AMD64, ARM, M1, RISC-V, ...).

Regards. [...]

Where do you see tcc to be unstable?

Yes, the last patch is ugly and should be removed or fixed
(path is created with alloca and later overwritten with malloc),
and that patch is only used as fallback,
when CONFIG_TCCDIR is undefined.

Primary goals for tcc are:
* Compile to correct code,
* as fast as possible,
* while being as simple as possible


For memory leaks from malloc, which are only freed at program shutdown:
A design decision is not a bug.
* tcc is a short running program,
   and a design decission to not free every memory from malloc
   is also done by other compiler for speed reasons:
   (look at DMC or DMD as examples.)
   (i dont know, if both compiler do not free, but i can remember,
    that walter bright wrote, not to free memory was his
    design decision for speed reasons).
* things done in libtcc are different,
   as the programm, which is using libtcc might live longer.
   I would suggest to fix memory leaks in libtcc.


For using an object format, with is not the same, what most other compiler
use on that system:
A design decision, and not a bug
Disadvantage:
* You can't link object files from other compiler
Advantage:
* simplify the code generator, the linker and probably other tools

This is also done by other compiler for many Years:
* Watcom/OpenWatcom uses OMF
* Embarcadero C++ Builder:
   The newer compiler are based on clang
   and use ELF object files also on Windows

-​-
Regards ... Detlef


_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]