Re: [Tinycc-devel] make tcc reentrant

[Daniel Glöckner]

Hi,

On Sat, Dec 07, 2019 at 11:34:11AM +0100, Ulrich Schmidt wrote:
> - The in scenario1 unloved 1 function parameter can be ignored and the
> values stored locally:
>   #define LIBPARAM1
>   #define VALUE(v) v
>   ..
>
>   somereturn somefunc(LIBPARAM1 ...) {
>     VALUE(count) = 0;
>     ...
>
> - in scenario 2 we define the 2 macros different:
>   #define LIBPARAM1 TCCState *s1,
>   #define VALUE(v) s1->v

We need a macro

#if scenario == 1
#define PASSPARAM1
#else
#define PASSPARAM1 s1,
#endif

Grouping all globals in the TCCState structure might be beneficial
even if we don't switch to those macros, because of the cache locality
Christian wrote about. The VALUE macro in scenario 1 would then be
#define VALUE(v) global_state.v

Btw, has anyone thought about handling TCCState like the context is
handled in the OpenGL API? It has one function to select the context
to use for following operations and the operations themselves don't
have a parameter for the context. If the pointer to the TCCState is
stored in a normal or in a TLS variable is up to us and might even
be a compile time option (that is set to "normal" for compilation
with tcc as long as tcc doesn't know how to generate TLS variables).

Best regards,

  Daniel

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

Re: [Tinycc-devel] make tcc reentrant

[Ulrich Schmidt]

Hello.

After reading all your posts. I see there are 2 scenarios/goals in the
comunity.

scenario 1:
I want a tiny and fast c compiler (tcc/tcc.exe).
In this case the TCCSTate struct is not needed at all and dereferencing
TCCState fields slows down execution. Making TCCStruct fields local
would speed things up. libtcc.c needs to become compiled statically into
tcc.exe. You can execute tcc many times parallel without trouble and it
is fast as it can be.

scenario 2:
I want to use libtcc in my own application(libtcc.so/libtcc.so).
This library HAS to be reentrant and we need the TCCStruct and all
compiling state related values needs to be stored inside this struct.

These 2 scenarios result in different decisions about TCCState. Many
years ago (more than 6) someone decited to make tcc functionality
useable from other apps, put all relevant conde into libbtcc.c, defined
a api,created this TCCStruct and started the transition process. (you
can still find the comments //XXX: in the sources) this process never
finished.

The question is, how we deal with the situation. Right now i would not
provide a separate libtcc until the transition process came to a end.
Right now libtcc needs to be compiled statically into tcc.

So how can we comply with scenario 1 AND 2 at the same time? (just a
quick thought)
- make the state values local or struct fields by using defines and
macros...

- The in scenario1 unloved 1 function parameter can be ignored and the
values stored locally:
  #define LIBPARAM1
  #define VALUE(v) v
  ..

  somereturn somefunc(LIBPARAM1 ...) {
    VALUE(count) = 0;
    ...

- in scenario 2 we define the 2 macros different:
  #define LIBPARAM1 TCCState *s1,
  #define VALUE(v) s1->v

Right now tcc does not fit scenario 1 nor 2.

Ulrich.


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

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 > 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 
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