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