On Thu, Jan 3, 2019 at 11:04 AM uso ewin <uso.cosmo....@gmail.com> wrote: > > On Wed, Jan 2, 2019 at 7:48 PM Michael Matz <matz....@frakked.de> wrote: > > > > Hi, > > > > On Wed, 2 Jan 2019, uso ewin wrote: > > > > > I've try to add support to cleanup attribute to TCC: > > > https://github.com/cosmo-ray/tcc/tree/cleanup > > > > > > Are you interested in having this feature merge in mob ? > > > If yes it would be nice if someone could review my code > > > > As you found out the one-pass nature of TCC makes implementing this > > somewhat awkward. Though you found some inventive solution to this I > > don't particularly like it, specifically: > > > > * your use of tokens instead of a symbol ID in the cleanup attribute seems > > wasteful: in principle a cleanup is an association of a function > > (representable as its name, as ID) with a decl (a Sym), so that should > > be the only necessary thing, not the token string representing > > "func(&foo)" (when the cleanup is function "func" on decl "foo"). > Your right, I've use Token, because I have a better knowledge > of Token handling in TCC than function generation, > and it was easier to make the first version using Token, but I should have > change that before sending my mail here, > I'm presently working on making this change. > > > * 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. > 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. > 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. > > > I'm somewhat sympathetic to having that GCC extension, though it is one of > > the more arcane ones that isn't trivial to support and isn't used very > > often in the wild (did you have any software in mind that made you > > implement the extension?). > > I've implement this extension for a project of mine that have an entity > system, > where every entity have a refcont, so I want to add a macro that would > automatically decref my entities at scope exit (NEW_INT_ENTITY(my_int)). > > The only big project I know that use cleanup is Libvirt: > https://libvirt.org/git/?p=libvirt.git;a=search;h=HEAD;s=Sukrit+Bhatnagar;st=author > but I don't know if TCC can compile it. > They did this as a 2018 google summer of code project. >
glib allow to use this too: https://developer.gnome.org/glib/unstable/glib-Miscellaneous-Macros.html#g-autoptr > > So the advantage of having that extensions > > needs to be weighed fairly lightly against the disadvantage of > > complicating TCCs sources. IMHO your current implementation leans more on > > the disadvantage side. But maybe you can rework it somewhat along the > > remarks above and it turns out more elegant? > > > 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 ? > > Thanks for the review ! > Matthias, > > > > Ciao, > > Michael. > > > > _______________________________________________ > > Tinycc-devel mailing list > > Tinycc-devel@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/tinycc-devel _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
