[Top][All Lists]

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

Re: [Tinycc-devel] make tcc reentrant

From: grischka
Subject: Re: [Tinycc-devel] make tcc reentrant
Date: Wed, 11 Dec 2019 03:58:33 +0100
User-agent: Thunderbird (Windows/20090812)


Couldn't help to try out some things, related to the matter.

Anyway I think, it still does look like tinycc.

--- grischka

ag wrote:

And at the end is always about mechanics and mechanism[s] (funny).

First is the tcc underlying machine. Should be fast. No compromises. Direct
access to the underlying physical machine. This is C and its property. We take
some risks we want results. Optimum results. Otherwise goto the abstraction.
C has almost no abstraction (probably is more like a tiny bits of convenience).

With multi-threading though, the underlying machine tcc code, should account for
side effects of the shared execution space, so adds even a tiny bit (and with 
best of efforts) of complexity. So that is not quite primitive and it seems like
a condradiction with the "direct access to the machine" thing. It's even is a 
of odd, that tcc which is a C compiler, to use "second thoughts" in its C code.

But as (almost) always staring at the code reveals the answer. I never done 
i saw some and always look (oh well) complicated! (for the C way of thinking), 
as it
is perhaps the only code that scanning stops and the mind should start to think 
in an
unusual way.

State though can encapsulate all what they need to make them work without 
And since it is their data and their methods, and if at some point they 
that data, perhaps they can feel more certain and could apply some optimizations
(e.g., uneeded conditional branches) and even gain some speed at the end.

But states could not let them without a supervisor or (anyway) is wise to 
one. As Michael said, there is a need to think hard here to avoid complexity and
without loosing speed.  Compilation speed is all what matters to tcc (foremost) 
as a
development tool. Tcc compiles more than 15000 lines library code in a fraction 
of a
second, when gcc takes 19 and clang 24. When you only want to inspect some 
this can speed a whola lot of time the development process, as sometimes this 
gets really intensive and it might happens quite of times in the row. In 
(almost 2
years now experience with tcc) tcc produces identical results with gcc with -O2 
-Wall -Werror, while gcc and clang disagree sometimes.

What this supervisor or the root state of those states will do is discussable.
It can perhaps impose some strictness of the state objects visibility, or it can
pass messages between them, or perhaps it could be used as a wise try/catch 
or it can handle communication outside of its parent group pid, or it can even 
used with the same way with a higher level language (it can be set for 
instance, an
intermediate function)). But here we are starting to talking like tcc is a 
language, but why not? If we could use a very strict subset of C (a C--) we 
could cut
roads and be faster. Perhaps we could have a way to instruct tcc, that only for 
will make sence, even for a second pass! For instance to optimize a block or a 
where performance matters. Right now no code has special treatment. Perhaps it 
be wise to have.

The above make sence with the regards to flexibility and mainly about the user 
to do whatever she likes todo without to have to pay a lot o price (like 
multiply tcc
instances: but this seems like quite of complex task, and besides that is 
(and we all know that economy matters here!)).

In any case the objects should be (naturally) opaque pointers.

How this can be implemented? My favorite way it to pass my objects or states as 
first argument of the function, and having a root linked list (usually double) 
a head and a tail and with a current pointer, to control them; plus an index 
and the number of the states. But in this case manifested, that pointer 
adds (even) a small of an overhead so this might be out of the discussion, but 
is quite technical and its far away the time (they say you need at least 20 
years of
experience in C), to know the prudent way (though i saw/see people with more 
than 40
years of experience (both) to disagree sometimes about the technical details).

But as always there always afterthoughts but discussion surely helps, (damn too 
always, it's getting absolutism).



reply via email to

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