[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] make tcc reentrant

From: Michael Matz
Subject: Re: [Tinycc-devel] make tcc reentrant
Date: Mon, 9 Dec 2019 15:42:46 +0000 (UTC)
User-agent: Alpine 2.21 (LSU 202 2017-01-01)


[sorry for the flurry of mails, I probably should have responded once to a 
set of mails :) ]

On Sat, 7 Dec 2019, Ulrich Schmidt wrote:

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

And here's the crux: define "compiling state related values".  Is the 
memory allocator part of that?  The token hash table?  The sections?  
The symbol table?  Do all of those really need to become per-state?  Do we 
really need to support multi-threading at a finer grain level than a BCL 
(big compiler lock :) )?

Depending on the answers to those (and more) questions you'll arrive at 
different solutions that are more or less appealing.  For some sets of 
answers there's no reason to differ between scenario 1 and 2, and ergo no 
need to introduce syntax stunts to support both.  I'd say that should be 
the preference.  (See my other answer to Christian as well)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]