tinycc-devel
[Top][All Lists]
Advanced

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

Re: [Tinycc-devel] make tcc reentrant


From: Michael Matz
Subject: Re: [Tinycc-devel] make tcc reentrant
Date: Wed, 11 Dec 2019 14:44:39 +0000 (UTC)
User-agent: Alpine 2.21 (LSU 202 2017-01-01)

Hi,

On Wed, 11 Dec 2019, grischka wrote:

> Couldn't help to try out some things, related to the matter.
> See
> https://repo.or.cz/tinycc.git/commitdiff/72729d8e360489416146d6d4fd6bc57c9c72c29b

Yeah, something like that was in my mind as well.

> Anyway I think, it still does look like tinycc.

Indeed, nice, I like it!  But let me disagree with parts of one comment 
you added:

+    /* Here we enter the code section where we use the global variables for
+       parsing and code generation (tccpp.c, tccgen.c, <target>-gen.c).
+       Other threads need to wait until we're done.
+
+       Alternatively we could of course pass TCCState *s1 everwhere
+       except that it would look extremly ugly.
+
+       Alternatively we could use thread local storage for those global
+       variables, which may or may not have advantages */

The last alternative really isn't one.  If you move some global variables 
to be thread-local, you now have multiple potentially different copies.  
Some TCCState state refers to the global (then thread-local) variables 
(e.g. symbol table or string/token indices), so you'd have to associate 
each TCCState with the specific instance of the thread-local to which it 
wants to refer.  Now you either have bound each TCCState to a specific 
thread, or you need to introduce locking again because you might refer to 
data from different threads, which thread-locality was supposed to avoid.  
The only reason why the current scheme works is because there's only a 
single copy of the global data.  Having multiple copies (e.g. by 
introducing thread-local) effectively means you have to move that data 
into TCCState itself (at which point thread-local become moot again).


Ciao,
Michael.
> --- 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 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,
> >   Αγαθοκλής
> >
> 
> 
> _______________________________________________
> Tinycc-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> 

reply via email to

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