tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: uso ewin
Subject: Re: [Tinycc-devel] Add gcc cleanup attribute support
Date: Sun, 6 Jan 2019 19:35:35 +0100

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]