[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] make tcc reentrant
Re: [Tinycc-devel] make tcc reentrant
Wed, 11 Dec 2019 14:44:39 +0000 (UTC)
Alpine 2.21 (LSU 202 2017-01-01)
On Wed, 11 Dec 2019, grischka wrote:
> Couldn't help to try out some things, related to the matter.
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
+ /* 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).
> --- 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
- Re: [Tinycc-devel] make tcc reentrant, (continued)
- Re: [Tinycc-devel] make tcc reentrant, Christian Jullien, 2019/12/07
- Re: [Tinycc-devel] make tcc reentrant, Michael Matz, 2019/12/09
- Re: [Tinycc-devel] make tcc reentrant, Domingo Alvarez Duarte, 2019/12/09
- Re: [Tinycc-devel] make tcc reentrant, ag, 2019/12/10
- Re: [Tinycc-devel] make tcc reentrant, Forrest Curo, 2019/12/10
- Re: [Tinycc-devel] make tcc reentrant, grischka, 2019/12/10
- Re: [Tinycc-devel] make libtcc reentrant, Ulrich Schmidt, 2019/12/11
- Re: [Tinycc-devel] make libtcc reentrant, grischka, 2019/12/11
- Re: [Tinycc-devel] make libtcc reentrant, Karl Yerkes, 2019/12/11
- Re: [Tinycc-devel] make libtcc reentrant, uso ewin, 2019/12/12
- Re: [Tinycc-devel] make tcc reentrant,
Michael Matz <=
- Re: [Tinycc-devel] make tcc reentrant, uso ewin, 2019/12/12
- Re: [Tinycc-devel] make tcc reentrant, grischka, 2019/12/12
- Re: [Tinycc-devel] make tcc reentrant, Michael Matz, 2019/12/14
- Re: [Tinycc-devel] make tcc reentrant, grischka, 2019/12/16