Re: [Tinycc-devel] Making tinycc fully reentrant

[grischka]

Domingo Alvarez Duarte wrote:
> Hello again grischka !
>
> I finally managed to get a github workflow to build my reentrant fork of
> tinycc on linux, osx and windows.
>
> Actually there is two builds:
>
> - one with CONFIG_TCC_SEMLOCK set to ONE here
> https://github.com/mingodad/tinycc/actions/runs/1378248438
>
> - and another with CONFIG_TCC_SEMLOCK set to ZERO here
> https://github.com/mingodad/tinycc/actions/runs/1378259299 and it seems
> that in both all tests pass.
>
> Obs: You can clcik on individual builds to see the build/test output.
>
> Please if anyone is willing to test it and give any feedback I'll
> appreciate.

Sorry, forgot to mention i386-windows.  The problem seen obviously
was caused by the 2 static globals still present in i385-gen.c.

So with that corrected I can report that the 3rd test of
libtcc_test_mt
    "running tcc.c in threads to run fib"
actually runs faster with your version (here, with 2 CPU cores.
~1600ms, compared to ~2600ms with the semaphore lock).

Whether any practical project exists or ever will exist that would
benefit from that is another question.  One could think of a tcc
able to compile several files in parallel for example, but maybe
people will more likely stick to make -j instead.

--- grischka

> Cheers !
>
> On 23/10/21 17:29, grischka wrote:
> > Domingo Alvarez Duarte wrote:
> > > Hello Christian !
> > >
> > > Thank you for reply !
> > >
> > > I also noticed that there was some problems when trying to compile for
> > > arm64 on Android under termux.
> > >
> > > I'll put my changes here now https://github.com/mingodad/tinycc.
> > >
> > > I did reverted all my changes !
> > >
> > > Cheers !
> >
> > Hi Domingo,
> >
> > I'd say at least this is good enough to make some performance tests.
> > (Here it seems about 4% slower with gcc, 6% with msvc)
> >
> > It doesn't seem to fulfill its promise thoug, that is libtcc_test_mt
> > doesn't seeom to pass with CONFIG_TCC_SEMLOCK set to 0,
> >
> > Many of the 10000+ lines changed could be avoided if one sticked
> > simply with 's1' instead of 'S'.  In fact the files not defining
> > USING_GLOBALS already are fully reentrant (except some functions
> > dealing with BufferedFile in libtcc.c which would rather belong to
> > tccpp.c in fact).
> >
> > Of course such invasive change will cause many problems for everyone
> > who may have patches still laying around intended to be rebased and
> > published at some point in the future.  The same problems that you
> > will have to rebase your patch on other peoples patches that may
> > come in in future.
> >
> > This was also the main reason why I dropped the idea of "s1 everywhere"
> > in 2019 and decided to go with the "quasi-reentrancy" using a semaphore
> > for some regions/files (tccpp, tccgen, gen-xxx, see commit 72729d8e3604).
> >
> > Beside that I was looking for a "one-click" conversion method rather than
> > a "three days of work" method.  IIRC I've made some progress based on a
> > "tcc -E -C ..." patch that allows to retain comments and with some
> > extensions, also preprocessor statements, such that tcc -E was able
> > to output basically identical files.  The plan then was of course to
> > feed it with "#define tok s1->tok" etc. and have everything rewritten
> > including function protos and calls with just some commands from a shell
> > script. ;)
> >
> > --- grischka
> >
> > > On 22/10/21 6:00, Christian Jullien wrote:
> > > > Hi Domingo,
> > > > Thank you for your attempt to make tcc better. However, please never
> > > > commit huge changes like this without making a branch before **and**
> > > > ask maintainers if they agree (I'm not a maintainer but an enthusiast
> > > > user).
> > > > So I strongly suggest you revert your all changes as, among others, it
> > > > breaks
> > > >
> > > > - Windows:
> > > > ../tccpe.c:871: warning: assignment from incompatible pointer type
> > > > In file included from ../tcc.c:25:
> > > > ../tcctools.c:442: error: 'S' undeclared
> > > >
> > > > - macOS
> > > > In file included from tcc.c:21:
> > > > In file included from ./tcc.h:362:
> > > > ./libtcc.h:28:16: error: typedef redefinition with different types
> > > > ('long' vs '__darwin_off_t' (aka 'long long'))
> > > >    typedef long off_t;
> > > >                 ^
> > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types/_off_t.h:31:33:
> > > >
> > > > note: previous definition is here
> > > > typedef __darwin_off_t          off_t;
> > > >
> > > > Christian
> > > >
> > > > -----Original Message-----
> > > > From: Tinycc-devel
> > > > [mailto:tinycc-devel-bounces+eligis=orange.fr@nongnu.org] On Behalf Of
> > > > Domingo Alvarez Duarte
> > > > Sent: Thursday, October 21, 2021 20:19
> > > > To: tinycc-devel@nongnu.org
> > > > Subject: [Tinycc-devel] Making tinycc fully reentrant
> > > >
> > > > Hello !
> > > >
> > > > I did it once in the past and did again moving almost all global
> > > > variables to TCCState and on Ubuntu 18.04 x86_64 all tests from "make
> > > > test" pass.
> > > >
> > > > It's a massive refactoring (3 full working days).
> > > >
> > > > Any comments/suggestions are welcome !
> > > >
> > > > Cheers !
> >
> > _______________________________________________
> > Tinycc-devel mailing list
> > Tinycc-devel@nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/tinycc-devel