Re: [Tinycc-devel] Add gcc cleanup attribute support

[uso ewin]

On Tue, Jan 15, 2019 at 1:20 PM uso ewin <address@hidden> wrote:
>
> On Fri, Jan 11, 2019 at 8:10 PM uso ewin <address@hidden> wrote:
> >
> > On Tue, Jan 8, 2019 at 8:42 PM uso ewin <address@hidden> wrote:
> > >
> > > 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 <address@hidden> wrote:
> > > >
> > > > On Fri, Jan 4, 2019 at 10:27 AM uso ewin <address@hidden> wrote:
> > > > >
> > > > > On Thu, Jan 3, 2019 at 6:51 PM Michael Matz <address@hidden> 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
> > > > > > address@hidden
> > > > > > 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
> >
> > new version that don't use dual parsing:
> > https://github.com/cosmo-ray/tcc/tree/cleanup2
> >
> > any thoughts on this ?
> >
> > Thanks
> > Matthias
>
> Hi,
>
> As no one answer, can I push this on mod
> (the version without dual parsing) ?
>
>
> Matthias

Hello again,

I saw I had some bug in my last branch,
https://github.com/cosmo-ray/tcc/tree/cleanup2
so I've push -f fixes on it

I'm going to wait until Wednesday to see if someone is
against my patch, if I receive no complaint I will push on mob

Thanks,
Matthias