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 > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel >
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
