Re: [Tinycc-devel] make tcc reentrant

[Domingo Alvarez Duarte]

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 <address@hidden> 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
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel