Re: [Tinycc-devel] bounds checking
I hope I fixed this now. I attached the wine Makefile I used. Could you update sourceforge? Regards, Herman On 2019-12-10 08:35, Christian Jullien wrote: Hello Herman, === Compiling with your patch on ARM (32bit) gives this error: test3 ../tcc -B.. -I../include -I.. -I.. -DCONFIG_TRIPLET="\"arm-linux-gnueabihf\"" -DTCC_CPU_VERSION=7 -DTCC_TARGET_ARM -DTCC_ARM_EABI -DTCC_ARM_HARDFLOAT -DTCC_ARM_VFP -run ../tcc.c -B.. -I../include -I.. -I.. -DCONFIG_TRIPLET="\"arm-linux-gnueabihf\"" -DTCC_CPU_VERSION=7 -DTCC_TARGET_ARM -DTCC_ARM_EABI -DTCC_ARM_HARDFLOAT -DTCC_ARM_VFP -run ../tcc.c -B.. -I../include -I.. -I.. -DCONFIG_TRIPLET="\"arm-linux-gnueabihf\"" -DTCC_CPU_VERSION=7 -DTCC_TARGET_ARM -DTCC_ARM_EABI -DTCC_ARM_HARDFLOAT -DTCC_ARM_VFP -run ../tcc.c -B.. -I../include -I.. -I.. -run tcctest.c > test.out3 --- test.ref2019-12-10 08:31:02.487022330 +0100 +++ test.out3 2019-12-10 08:31:03.257006236 +0100 @@ -749,4 +749,4 @@ attr: 7 7 attr: 16 16 0a - +0014 make[2]: *** [Makefile:106: test3] Error 1 === Compiling with your patch on Aarch64 (AMR64) gives this error: make[1]: Entering directory '/home/jullien/tinycc/lib' ../tcc -c lib-arm64.c -o lib-arm64.o -B.. -g -Wno-deprecated-declarations ../tcc -c dsohandle.c -o dsohandle.o -B.. -g -Wno-deprecated-declarations ../tcc -ar rcs ../libtcc1.a lib-arm64.o dsohandle.o ../tcc -ar rcs ../libtccb1.a usage: tcc -ar [rcsv] lib file... create library ([abdioptxN] not supported). make[1]: *** [Makefile:90: ../libtccb1.a] Error 1 make[1]: Leaving directory '/home/jullien/tinycc/lib' make: *** [Makefile:246: libtcc1.a] Error 2 -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Herman ten Brugge via Tinycc-devel Sent: Tuesday, December 10, 2019 08:26 To: Herman ten Brugge via Tinycc-devel Cc: Herman ten Brugge Subject: [Tinycc-devel] bounds checking I just committed a large patch that fix a lot of bounds checking problems. I tested the bounds checking code now works on x86_64 and i386 on linux and windows. The test/tests2 directory can now be tested with -b enabled. There are a lot of changes (not complete): - split up bcheck.c from libtcc1.a because I now use dl_sym to redirect malloc and friends. This was needed because the malloc_hooks are not thread safe. When compiling with -b now the pthread and dl library are also included. - Rewrote bcheck.c library to fix a lot of small problems. - Add mmap/munmap support on linux. - Updated tcc.1 - Added bound_main_arg to record argv on startup. - Added support for x86_64 on windows. - Moved tcc_add_bcheck from tccelf to i386/x86_64 code. - Added 2 new testcases. - Fixed a lot of bugs: - conversion problem code with double/long long. - in gen_bounded_ptr_add move save_regs to top. - alloca/vla fixes. - VT_LLOCAL problems when using bounds checking. - ... Regards, Herman ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel # # This Makefile builds native Windows tcc for both 32 and 64 bits generator. # This makefile is adjusted from 'https://sourceforge.net/projects/wintcc/' # It requires mingw64 (and static libs for dl and pthread) and wine installed on linux. # by a second stage to compile tcc it self. # Generated binaries do not require cygwin to run. # You can launch 'tarball' target to build a tar.gz you can install on any # Windows machines. CPU = $(shell if `x86_64-w64-mingw32-gcc -v 2>&1 | grep Target | grep -q x86_64`; then echo 64; else echo 32; fi) VERSION = $(shell cat ../VERSION) BOOTCC = x86_64-w64-mingw32-gcc CFLAGS = -s -static -fno-strict-aliasing -Wno-incompatible-pointer-types -DTCC_TARGET_PE #WINPWD = `cygpath --mixed $(PWD)` #@echo "#define CONFIG_TCCDIR \"$(WINPWD)\"" ifeq ($(CPU), 64) NATIVE = -m$(CPU) -DTCC_TARGET_X86_64 ARCH= x86_64 else NATIVE = -m$(CPU) -DTCC_TARGET_I386 ARCH= i386 endif TARGET = $(CPU) ifeq ($(TARGET), 64) TFLAGS = -m$(TARGET) -DTCC_TARGET_X86_64 TARCH = x86_64 else TFLAGS = -m$(TARGET) -DTCC_TARGET_I386 TARCH = i386 endif all: pre bootstrap libs rebuild @chmod 775 *.exe @ls -ls *.exe pre: @echo ARCH=$(TARCH) 1> ../config.mak @echo TARGETOS=Windows 1>> ../config.mak @echo CONFIG_WIN32=yes 1>> ../config.mak @echo TOPSRC=$$\(TOP\) 1>> ../config.mak @echo EXESUF=.exe 1>> ../config.mak @echo "#define TCC_VERSION \"$(VERSION)\"" 1>../config.h @echo "#ifdef TCC_TARGET_X86_64" 1>>../config.h @echo "#define TCC_LIBTCC1 \"libtcc1-64.a\"" 1>>../config.h @echo "#define TCC_LIBTCCB1 \"libtccb1-64.a\"" 1>>../config.h @echo "#else" 1>>../config.h @echo "#define TCC_LIBTCC1 \"libtcc1-32.a\"" 1>>../config.h @echo "#define TCC_LIBTCCB1 \"libtccb1-32.a\"" 1>>../config.h
[Tinycc-devel] 111_conversion.c with bounds checking
I still have one small problem with testcase 111_conversion.c
The problem is that it fails on i386.c (linux) when compiling with:
tcc 111_conversion.c -o 111_conversion -b
./111_conversion
I fixed this (and commited it in git) with the following patch in tccgen.c:
if ((p->r2 & VT_VALMASK) < VT_CONST) {
size *= 2;
align *= 2;
}
This is probably not correct and should be fixed some where else.
Can someone who understands tcc better help me with this.
Thanks,
Herman
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] bounds checking
Hello Herman, === Compiling with your patch on ARM (32bit) gives this error: test3 ../tcc -B.. -I../include -I.. -I.. -DCONFIG_TRIPLET="\"arm-linux-gnueabihf\"" -DTCC_CPU_VERSION=7 -DTCC_TARGET_ARM -DTCC_ARM_EABI -DTCC_ARM_HARDFLOAT -DTCC_ARM_VFP -run ../tcc.c -B.. -I../include -I.. -I.. -DCONFIG_TRIPLET="\"arm-linux-gnueabihf\"" -DTCC_CPU_VERSION=7 -DTCC_TARGET_ARM -DTCC_ARM_EABI -DTCC_ARM_HARDFLOAT -DTCC_ARM_VFP -run ../tcc.c -B.. -I../include -I.. -I.. -DCONFIG_TRIPLET="\"arm-linux-gnueabihf\"" -DTCC_CPU_VERSION=7 -DTCC_TARGET_ARM -DTCC_ARM_EABI -DTCC_ARM_HARDFLOAT -DTCC_ARM_VFP -run ../tcc.c -B.. -I../include -I.. -I.. -run tcctest.c > test.out3 --- test.ref2019-12-10 08:31:02.487022330 +0100 +++ test.out3 2019-12-10 08:31:03.257006236 +0100 @@ -749,4 +749,4 @@ attr: 7 7 attr: 16 16 0a - +0014 make[2]: *** [Makefile:106: test3] Error 1 === Compiling with your patch on Aarch64 (AMR64) gives this error: make[1]: Entering directory '/home/jullien/tinycc/lib' ../tcc -c lib-arm64.c -o lib-arm64.o -B.. -g -Wno-deprecated-declarations ../tcc -c dsohandle.c -o dsohandle.o -B.. -g -Wno-deprecated-declarations ../tcc -ar rcs ../libtcc1.a lib-arm64.o dsohandle.o ../tcc -ar rcs ../libtccb1.a usage: tcc -ar [rcsv] lib file... create library ([abdioptxN] not supported). make[1]: *** [Makefile:90: ../libtccb1.a] Error 1 make[1]: Leaving directory '/home/jullien/tinycc/lib' make: *** [Makefile:246: libtcc1.a] Error 2 -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Herman ten Brugge via Tinycc-devel Sent: Tuesday, December 10, 2019 08:26 To: Herman ten Brugge via Tinycc-devel Cc: Herman ten Brugge Subject: [Tinycc-devel] bounds checking I just committed a large patch that fix a lot of bounds checking problems. I tested the bounds checking code now works on x86_64 and i386 on linux and windows. The test/tests2 directory can now be tested with -b enabled. There are a lot of changes (not complete): - split up bcheck.c from libtcc1.a because I now use dl_sym to redirect malloc and friends. This was needed because the malloc_hooks are not thread safe. When compiling with -b now the pthread and dl library are also included. - Rewrote bcheck.c library to fix a lot of small problems. - Add mmap/munmap support on linux. - Updated tcc.1 - Added bound_main_arg to record argv on startup. - Added support for x86_64 on windows. - Moved tcc_add_bcheck from tccelf to i386/x86_64 code. - Added 2 new testcases. - Fixed a lot of bugs: - conversion problem code with double/long long. - in gen_bounded_ptr_add move save_regs to top. - alloca/vla fixes. - VT_LLOCAL problems when using bounds checking. - ... Regards, Herman ___ 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] bounds checking
I just committed a large patch that fix a lot of bounds checking problems. I tested the bounds checking code now works on x86_64 and i386 on linux and windows. The test/tests2 directory can now be tested with -b enabled. There are a lot of changes (not complete): - split up bcheck.c from libtcc1.a because I now use dl_sym to redirect malloc and friends. This was needed because the malloc_hooks are not thread safe. When compiling with -b now the pthread and dl library are also included. - Rewrote bcheck.c library to fix a lot of small problems. - Add mmap/munmap support on linux. - Updated tcc.1 - Added bound_main_arg to record argv on startup. - Added support for x86_64 on windows. - Moved tcc_add_bcheck from tccelf to i386/x86_64 code. - Added 2 new testcases. - Fixed a lot of bugs: - conversion problem code with double/long long. - in gen_bounded_ptr_add move save_regs to top. - alloca/vla fixes. - VT_LLOCAL problems when using bounds checking. - ... Regards, Herman ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] make tcc reentrant
Hello, On Mon, 9 Dec 2019, Ulrich Schmidt wrote: > Am 09.12.2019 um 16:42 schrieb Michael Matz: > > 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:) )? > > compiling state related values: > All values changable betwen tcc_new() call and tcc_delete() call. Only those explicitely changable via API calls, or those changed internally as well? I guess you mean the former, then it follows that e.g. the token hash table and internal memory allocator can remain shared, as can the expr evaluation stack and many parts of the code generator (always with the mental model that the API calls serialize). Symbol table and sections would be border line, as those can be influenced by what you throw into tcc_compile_string. I guess you would want to be able to have two states s1 and s2, and define two different 'main' functions in the two states, right? I think that and similar things can be accomplished without triggering any of the concerns I have with the fully-reentrant-fine-grained solution. You mentioned that you had to add many TCCState arguments merely for the sake of tcc_error. Would it perhaps be enough for you to register only a single error callback function if it were given the 'current' TCCState magically? (I'm thinking of a solution where the API calls, which already always get a TCCState would act as critical sections and therefor could overwrite/restore the global tcc_state variable, and thereby reduce the syntactic impact of these changes) Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] make tcc reentrant
Am 09.12.2019 um 16:42 schrieb Michael Matz: 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:) )? compiling state related values: All values changable betwen tcc_new() call and tcc_delete() call. Greetings. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] make tcc reentrant
Hello, [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) Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] make tcc reentrant
Hello ! We can have direct measure using https://github.com/mingodad/tinycc that already does/did the transformation to make tinycc reentrant and maybe revive it. Cheers ! On 9/12/19 16:33, Michael Matz wrote: Hi, On Sat, 7 Dec 2019, Christian Jullien wrote: 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. In fact, I experimented the opposite. When moving all global variables to a struct, my Lisp was around 1% faster because globals are now close together and more often accessible from L1 cache. They are equally close in the .data section/segment, as long as you put _all_ global data into that struct (which is what was proposed). I do believe you that it was faster, merely pointing out that it probably had other reasons. Either way, I measured with TCC itself, not some other program with completely different behaviour. Specifically the accesses to the token hash table from the pre-processor (tokenization is the slowest part in TCC, as it should be) currently needs only one register, because the address of that table is an immediate. Just changing this to be a pointer (cached in a register), with otherwise similar code made the inner loop of tokenization measurably slower (though I don't remember the percentage anymore, but I was thinking "meeh"). The effect is that on x86-64 the computation either needs a slow addressing mode, or multiple instructions (which are dependend then), which alone caused this slowdown. Of course, we could decide that a (say) 2% slowdown in compilation speed is acceptable for the feature of multiple compiler states that don't have to interact. Or we could think long and hard about what we really want/need from our APIs and try to get both. E.g. it's not clear that the token hash table really needs to become a non-singleton, even _if_ we'd allow multiple TCCState objects. It's just that the update to the token hash must not be done concurrently. So, we could for instance allow and support multiple TCCStates but _without_ multi-threading. Or (like grischka said) allow multi-threading, but only on the API level (and serialize internally). So, I think the latter is the solution with the most bang for the buck: allow multiple TCCStates, but don't necessarily move all global data into the state, under the assumption that at its core TCC remains single-threaded. We'd also still have to decide what multiple TCCStates really mean: e.g. I'd say this is only for compiling to memory. That would mean that it's not really necessary for the code from different states to be generated into different sections. Though finalization needs to be per state, so maybe it's unavoidable, but that needs to be tried. There might be other global data (e.g. the memory allocator) that also could remain shared between different states. (Again, all with the assumption that multi-threading is serialized high in the API level). Ciao, Michael. It has of course no effect when global is a pointer which introduces the same indirection. It is true for aggressive optimizers which are likely to put struct pointer to a register. So it may be faster for tcc compiled by gcc, clang or vc++ but slower when tcc is compiled by tcc. C. -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Michael Matz Sent: Friday, December 06, 2019 16:42 To: TCC mailing list Subject: Re: [Tinycc-devel] make tcc reentrant 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
Re: [Tinycc-devel] make tcc reentrant
Hi, On Sat, 7 Dec 2019, Christian Jullien wrote: > > 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. > > In fact, I experimented the opposite. When moving all global variables > to a struct, my Lisp was around 1% faster because globals are now close > together and more often accessible from L1 cache. They are equally close in the .data section/segment, as long as you put _all_ global data into that struct (which is what was proposed). I do believe you that it was faster, merely pointing out that it probably had other reasons. Either way, I measured with TCC itself, not some other program with completely different behaviour. Specifically the accesses to the token hash table from the pre-processor (tokenization is the slowest part in TCC, as it should be) currently needs only one register, because the address of that table is an immediate. Just changing this to be a pointer (cached in a register), with otherwise similar code made the inner loop of tokenization measurably slower (though I don't remember the percentage anymore, but I was thinking "meeh"). The effect is that on x86-64 the computation either needs a slow addressing mode, or multiple instructions (which are dependend then), which alone caused this slowdown. Of course, we could decide that a (say) 2% slowdown in compilation speed is acceptable for the feature of multiple compiler states that don't have to interact. Or we could think long and hard about what we really want/need from our APIs and try to get both. E.g. it's not clear that the token hash table really needs to become a non-singleton, even _if_ we'd allow multiple TCCState objects. It's just that the update to the token hash must not be done concurrently. So, we could for instance allow and support multiple TCCStates but _without_ multi-threading. Or (like grischka said) allow multi-threading, but only on the API level (and serialize internally). So, I think the latter is the solution with the most bang for the buck: allow multiple TCCStates, but don't necessarily move all global data into the state, under the assumption that at its core TCC remains single-threaded. We'd also still have to decide what multiple TCCStates really mean: e.g. I'd say this is only for compiling to memory. That would mean that it's not really necessary for the code from different states to be generated into different sections. Though finalization needs to be per state, so maybe it's unavoidable, but that needs to be tried. There might be other global data (e.g. the memory allocator) that also could remain shared between different states. (Again, all with the assumption that multi-threading is serialized high in the API level). Ciao, Michael. > It has of course no effect when global is a pointer which introduces the > same indirection. It is true for aggressive optimizers which are likely > to put struct pointer to a register. So it may be faster for tcc > compiled by gcc, clang or vc++ but slower when tcc is compiled by tcc. > > C. > > -Original Message- > From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] > On Behalf Of Michael Matz > Sent: Friday, December 06, 2019 16:42 > To: TCC mailing list > Subject: Re: [Tinycc-devel] make tcc reentrant > > 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
Re: [Tinycc-devel] make tcc reentrant
Hi, On Sat, 7 Dec 2019, Daniel Glöckner wrote: > 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. That's a red herring. All global data is also packed together, as it's all placed next to each other in .data, same as it would be when placed into one structure. (Of course you have more control over the specific layout, and that might matter sometimes, but just placing everything into a large struct doesn't change the properties of locality). > 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). The library API already takes a TCCState object (which is why it gives the impression that you actually can use multiple ones), so I don't think the public API should change to be OpenGL like. For the internal API ... yeah, maybe, though of course the state switching also adds clutter source-wise. Ciao, Michael.___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] make tcc reentrant
Hi,
On Sun, 8 Dec 2019, uso ewin wrote:
> I've made a version that should support multi thread on my github
> https://github.com/cosmo-ray/tcc/commit/46d0e73edc7e448f0f514936fdb4f62e2c8800a4
> I didn't tests it, it's just here to show the
> possibility using _Thread_local.
Ulrich doesn't care for multiple threads in and off itself, he cares for
multiple TCCState objects, i.e. multiple compiler instances. And for that
all global data (that necessarily are currently singletons) either needs
to move to that state or its updating needs to be harmless when faced
with multiple states. Having multiple copies of global data (one per
thread) _still_ doesn't allow multiple such states within one thread.
Ciao,
Michael.
>
> This approach even if it doesn't enable reentrancy,
> allow multy-thread, can be disable
> and doesn't modify a lot of code.
>
> Do you think you could use that Ulrich ?
>
> Thanks,
> Matthias
>
> On Sat, Dec 7, 2019 at 12:51 PM Daniel Glöckner wrote:
> >
> > 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
>
> ___
> 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
