Hello Christian and list, >> Since when do we tell other people what to do and until when, in tinycc? > I'm sorry about that. You're right it is not my role. Thanks for sharing your ideas and suggestions. Here are some of mine (which overlap some of what you mentioned):
Short: In general, keep doing what they have been doing on the compiler itself. Getting a list of project goals, priorities, and a policy on patches would help everyone. (If anarchy is the policy, that would be nice to know as well. ;) Consider an updated release. Long: My use of tcc includes: 1) Dynamic code compilation and execution for geometric modeling 2) R&D on reduced power consumption computing 3) Further study on compiler design/implementation, with a focus on minimalism 4) Work on compile-time meta-programming and OO with C I'm fairly sure 1 and 4 are going to require me to fork or rewrite tcc in a production system, due to code size/complexity increases--it would approach MediumCC. Item 3 is an important use for me, though, with the existing tcc. It is great to have a compact, comprehensible compiler like tcc as a model for study. Tcc is used in at least one minimal, reproducible bootstrapping project (GNU Mes, which mentions having to use a patched tcc--why I don't currently know). Tcc could have a role in Item 2, even substantially "as-is". One focus of tcc seems to be on compile-time performance, which is important during development for energy efficiency and shorter build turn-around-time. A compiler which generates more highly-optimized code could be used for released software. Currently, my 3D modeling software does textual C code generation from an external, pre-optimized AST, which is then dynamically compiled and run with an unpatched tcc. The dynamic code generation feature of tcc has been an very valuable feature for my prototype of this project. My suggestion of a list of priorities would be (in increasing order): A) Fix known bugs before adding new features B) Add regression tests for (A) C) Work towards more complete standard compliancy D) Add tests for demonstration of (C) E) Keep it simple, keep it small, keep compilation time fast F) Compatibility with other projects, (my opinionated list): a) the Linux kernel (version?) b) other tiny compilers like Mes or Femtolisp c) musl d) C container template library G) Additional external (gcc, MS) extensions, especially for platform support, remembering (E) Having a (not necessarily strict) list of priorities could reduce the workload of the devs/maintainers and reduce uncertainty when considering patches. -----Original Message----- From: Christian Jullien <eli...@orange.fr> To: tinycc-devel@nongnu.org Sent: Tue, Jun 22, 2021 5:18 am Subject: Re: [Tinycc-devel] TinyCC -std=c2x support? Hello Grischka, > Since when do we tell other people what to do and until when, in tinycc? I'm sorry about that. You're right it is not my role. I wrote this because I see many positive energies to improve TinyCC but we lack clear directives to where we want to go and what it is allowed to do or not. Some push (sometimes) wrong patches without asking other ask but get no replies. They give up or, worse, fork! I use daily tcc as my main C compiler but I still don't know what is its goal and where it goes. Among things I understand (unsorted), tcc is: - tiny, but it is no longer true, I prefer to say it is small. - fast to compile, really true this time - conforming to C standard (which ones?), what should be the main efforts? C90 probably almost complete C99 not complete, it lacks complex C11 most new features but other are missing C2X none, that's why I suggested to start support and add -sdt=c2x as -std=c11 - Able to compile Linux kernel, which version? Chase recently made this request: [FEATURE REQUEST] asm-goto and got no replies. Do we want to support him? - Compatible with gcc and VC++ (until which point?), for example to you want we add __faststorefence() to allow concurrent access of SQLite on Windows as recently proposed? About commits, it would be nice to have a rule, like summit a patch and expect a reply from maintainers within a "reasonable" amount of time: accepted, rejected, postponed, Another thing, I know it seems you're reluctant to make a new official version (e.g. 0.9.28) but many distributions use only the official and quite old 0.9.27 version and users complain with bugs which have been fixed long ago. That's why I added recently the git short version to -v option. Can you consider to make a new official version anytime soon? I probably miss many other things that will help us (and maintainers) to know how improve tcc. Christian P.S. we all love tcc -----Original Message----- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of grischka Sent: Monday, June 21, 2021 22:25 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] TinyCC -std=c2x support? Christian Jullien wrote: > Hi no one complains or comments, I suggest you push your patches end of June Since when do we tell other people what to do and until when, in tinycc? -- gr
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
