Hi I've fix my problem, cleanup should now work correctly on my github(I've push -f)
I will now work on a new branch to remove the dual parsing. Matthias. On Sun, Jan 6, 2019 at 7:35 PM uso ewin <uso.cosmo....@gmail.com> wrote: > > On Fri, Jan 4, 2019 at 10:27 AM uso ewin <uso.cosmo....@gmail.com> wrote: > > > > On Thu, Jan 3, 2019 at 6:51 PM Michael Matz <matz....@frakked.de> wrote: > > > > > > Hi, > > > > > > On Thu, 3 Jan 2019, uso ewin wrote: > > > > > > >> * your way of dealing with the "goto forward" problem is to read and > > > >> remember all tokens after the goto until you find the label (and if > > > >> so > > > >> do the cleanups), rereading all these tokens afterwards. > > > >> > > > >> This feels ugly and against the one-pass nature (and is quadratic > > > >> if you > > > >> have very many gotos); several alternatives come to mind, though I > > > >> haven't tried any of them to see if they result in less ugly code: > > > >> e.g. > > > >> you could remember all potentially scope-exiting gotos and check > > > >> them at > > > >> scope exit (redirecting them to the cleanup and then further to the > > > >> real > > > >> destination). > > > > > > > > Well, the problem with checking this at scope exit or at the label > > > > declaration > > > > is that as TCC do single pass generation, I can't go back and > > > > regenerate the goto. > > > > > > Not the goto, but you can adjust where the goto goes to. > > Ok, I did not think about the possibility to do that, > > but now you say that, I will definitively test this implementation. > > Thanks a lot for the idea. > > > You wouldn't > > > link these gotos in the label->jnext members, but in some on-the-side > > > structure (also remembering the ultimate label they would have to go to, > > > you could probably use the existing dynarray_* code). > > > When you reach a label definition you remove all pending gotos for that > > > label (they don't skip over the scope exit). When you reach a scope exit > > > all pending gotos must first go to the cleanup snippet and then to the > > > ultimate label. > > > > > > > A way to solve this would be either to create a switch case after each > > > > label > > > > that might need cleanup, or a dummy function for each goto in need. > > > > > > That latter is what you're essentially having right now: you check if the > > > current goto in question leaves the scope, and if so emit all the cleanup > > > code first and then the goto. I.e. for multiple gotos you repeat the > > > cleanup code. That seems a sensible approach (the switch approach might > > > lead to smaller code, but this shouldn't matter much here and is more > > > complicated). > > > > > > > Either way, the code needed to handle that would be a lot more complex > > > > that current implementation which is ~30line for handling the forward > > > > goto case > > > > and that is call only in scope that contain cleanup variable. > > > > > > Remembering gotos would also only be done when there are pending cleanups. > > > It might be that you're right that it would take even more code. But I'm > > > not so sure. The remembering and reiteration over tokens really gripes at > > > me. E.g. think about this code: > > > > > > { int a CLEANUP(foo); > > > ... goto later1; ... > > > ... goto later2; ... > > > large chunk of code > > > } > > > later1: > > > ... > > > later2: > > > > > > For both gotos you iterate over the large chunk of code shifting tokens > > > back and forth between the token strings and the parser. As I said, it's > > > a cute trick to get what you need, but there has to be a better way. > > > > > > We could also declare that forward jumps within scopes needing cleanups is > > > simply not supported in TCC (with an appropriate error message). I would > > > prefer even that crippling of the support compared to the token sifting. > > > > > > > If I use Sym but keep the dual parsing that would happen only > > > > when we have a goto forward and a scope containing cleanup, > > > > would the balance switch to the advantage side ? > > > > > > A bit, but the dual parsing makes me really unhappy :-) Do you have > > > cycles for trying an alternative approach to at least compare both? > > > > > > > > > Ciao, > > > Michael. > > > > > > _______________________________________________ > > > Tinycc-devel mailing list > > > Tinycc-devel@nongnu.org > > > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > > > > Well, I will at first remove the Token usage for cleanup call, because > > it's buggy and ugly. > > Then I will try to use label pointer for cleanup. > > As it should use a lot of tcc code that are still obscure to me, I > > might take time to do so. > > > > Thanks, > > Matthias. > > Hi, > > I've got some improvement on removing token usage, > and generate call directly: > It mostly work, except when I try to call a function > with a float(or double) pointer as parameter, > When a function with a float is call, > the function receive NULL, instead of the float pointer. > Here is the code I use to generate the call > https://github.com/cosmo-ray/tcc/blob/cleanup/tccgen.c#L4755 > > Can you help me with that ? > > Thanks, > Matthias _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel