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: Sagar Acharya
Subject: Re: [Tinycc-devel] Calling for Release 0.10.0
Date: Wed, 31 May 2023 18:07:55 +0200 (CEST)

Tinycc is no "toy compiler".

Let us not assign such names please. A small compiler is always superior to a 
big compiler. As long as tinycc generates least number of instructions being 
reasonably good doing so, it is a full fledged minimal compiler.

In my view, it should keep updated with latest versions of C.
Thanking you
Sagar Acharya
http://humaaraartha.in <https://humaaraartha.in>



31 May 2023, 18:39 by tinycc-devel@nongnu.org:

>
>
> 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
>>



reply via email to

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