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
the
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
bit
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
threading,
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
worries.
And since it is their data and their methods, and if at some point they
sanitized
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
implement
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
values
this can speed a whola lot of time the development process, as sometimes this
can
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
-g
-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
method,
or it can handle communication outside of its parent group pid, or it can even
been
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
programming
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
tcc
will make sence, even for a second pass! For instance to optimize a block or a
function
where performance matters. Right now no code has special treatment. Perhaps it
would
be wise to have.
The above make sence with the regards to flexibility and mainly about the user
freedom
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
uneconomical
(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
the
first argument of the function, and having a root linked list (usually double)
with
a head and a tail and with a current pointer, to control them; plus an index
pointer
and the number of the states. But in this case manifested, that pointer
indirection
adds (even) a small of an overhead so this might be out of the discussion, but
this
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
many
always, it's getting absolutism).
Ciao,
Michael.
Best,
Αγαθοκλής