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.
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
