Hello !
I went to the trouble of making tcc fully reentrant but it was not
accepted https://github.com/mingodad/tinycc which is sad.
Cheers !
On 6/12/19 22:16, Charles Lohr wrote:
Is there a reason you don't just compile tcc in tcc to make the tcc
instance that is basically then reentrant? I've used this trick a
while on things other than tcc, turning all global or static variables
in any C program into an object that can be created or deleted or
duplicated in a process space.
Charles
On Fri, Dec 6, 2019 at 11:46 AM ag <aga.chatzimani...@gmail.com
<mailto:aga.chatzimani...@gmail.com>> wrote:
On Fri, Dec 06, at 03:42 Michael Matz wrote:
> Hello,
>
> On Tue, 3 Dec 2019, Ulrich Schmidt wrote:
>
> > i try to write a lua binding for tcc. To work out propperly,
the tcc lib
> > needs to be reentrant.
>
> As demonstrated down-thread, that isn't correct. It doesn't
_need_ to be,
> it would be an feature. As usual with features it needs to be
measured
> against the downsides. The downsides for your proposed changes
are the
> following at least:
> 1) more complicated/boiler-platy source code of TCC (a TCCState
> argument almost everywhere)
> 2) slower code: most of the time the indirection through a pointer
> variable (the state) in comparison to a direct access to a
static
> variable doesn't matter. But it does matter for the
symbol/token
> table (and potentially for the register/evaluation stack). I
have
> measured this years ago for the token table, so this might or
might not
> still be the case.
>
> So, while I can see the wish for this feature, I don't
necessarily see
> that tcc should be changed to accomodate.
>
> If anything I would expect a _complete_ transition to exist, in
order to
> measure the impact. The worst thing that could happen is if
someone added
> TCCState arguments everywhere, moved some static variables to
that state,
> and then leaves: none of the features of this whole excercise
would be
> had, but all the downsides would be there.
>
> And yes, this is a big project. I really think it would be better
> if you simply write a wrapper for libtcc that ensures
single-threadedness
> and that regards TCCState as a singleton. I think such thing
would be
> well-suited in the TCC sources itself.
>
> (In a way it seems prudent for a tiny C compiler to only be
usable as a
> singleton)
I maybe understand, that a C compiler would be best as a
singleton, as a
state can influence unexpectedly the other states (unless (perhaps
like in
this case as it would be under Lua control) there is a mechanism
to handle
gracefully any errors)), and i can trust you about the "direct
access to static
variables", but how about an (probably predefined (even with a
compile option)
__array__ of states (under a single-thread), and expose it
generiously and with
a pleasure to the user responsibility, without tcc guilties (if any)?
Perhaps can even implement this mechanism (to have a control of
the environment)
by it's own.
Anyway C is unsafe by default (if it is that worry).
> Ciao,
> Michael.
Best,
Αγαθοκλής
> >
> > I took a look into the sources and found some comments
(XXX:...) and
> > started with removing
> >
> > the static var tcc_state. As a result allmost all lib
functions needs a
> > 1st parameter of
> >
> > type TCCState*. I did this in my own local branch and tcc is still
> > running :).
> >
> > But this is a really HUGE change. in addition most of the
local vars in
> > tccpp, tccgen, ... needs
> >
> > to be moved to TCCState. I can do that but at some points i
will have
> > some questions and i
> >
> > can only test on windows and probably on linux.
> >
> > My 1st question is: Are you interested in these changes or
should i do
> > this locally?
> >
> > I would like to this together with you.
> >
> >
> > Greetings.
> >
> > Ulrich.
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org <mailto: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
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
