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.
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-----
Sent: Monday, June 21, 2021 22:25
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