On 09/07/13 03:55, Carsten Haitzler (The Rasterman) wrote: > On Mon, 08 Jul 2013 18:00:15 +0100 Tom Hacohen <tom.haco...@samsung.com> said: > >> Hey guys, >> >> The hero Jeremy Zurcher has been playing around and looking for ways to >> improve Eo and address all the issues that have been raised by everyone. >> We revisited some old ideas, tried some new ideas and changed our >> compromises and preferences to better suit our needs (followed by the >> extensive trial period). We think we made things better and we'd like to >> hear your thoughts and suggestions. >> >> The code resides in devs/tasn/eo2. The differences are not major >> usage-wise (i.e eo_do), but are major internally and class-creation-wise. >> There's an example of the usage of the new API in the eo2test directory. >> The existing code-base hasn't been changed to use the new API, so >> there's not a lot to review. >> Eo2 is not complete, we'd like to hear your thoughts before finishing >> things. >> >> Major changes: >> 1. No more va_args, good ol' normal functions instead. > > good and bad. good as varags is a bit unwieldy. bad as in more symbols and > either more function calls inlined in app code OR more code in general inlined > (with macros or inline funcs). end result? unknown until we try. also another > bad... work to port the existing eo code over. without full details, amount of > work unknown. (missing git tree).
I think it's better to inline those in the app, yeah. I don't think a function call + an if are much to worry about. Amount of work is known: everything needs to be done. This is a draft, not even a complete solution. This example doesn't handle eo_do_super and the eo_data_scope_get. > >> 2. Functions are resolved in eo and then called directly, creating a >> "flatter" backtrace. >> 3. We can have return values (to some extent). >> 4. Less boiler-plate. >> 5. Looks like we'll be able to get rid of some code thanks to this change. >> 6. Possibly (probably) faster on platforms that pass parameters in >> registers. > > hmm unlikely as now its: > 1 func to begin > 2 func to end > 2 func call s per method Yeah, but OTOH parameters will be passed in registers instead of the stack. I guess you are right though. > > as opposed to 1 func for begin+end, 1 func per method. i done see eo2 in git, > so i can only comment on the point here, not the code. (if the lookup is a > macro to get the func ptr, then call it directly, then sure, 2 fn call per > method). another downside to it all being macros.. code size goes up, this > instruction cache coherency goes down... :/ It's not all macros, code is there. :) >> 7. Easier to do breakpoint on a specific eo_do call, instead of an >> implementation. >> >> What we'd still like to achieve: >> 1. Being able to drop the IDs in favour for more "friendly" IDs. It'd be >> best to find a way to use the function pointers (for example) as the >> IDs, but the problem is, that because function pointers are more >> "unknown" we can do less optimisations on them which we'd like to avoid. >> 2. Reduce more boiler-plate. >> >> Haven't been implemented yet: eo_do_super (among many other things). >> >> Additional comments: >> EO_FUNC - this one creates a function that resolves and returns the >> appropriate function. The functions created using this macro should be >> used instead of the current eo macros. This one can potentially be improved. >> eo2_do_start/end are just the entry/exit hooks of eo2_do (ref/unref and >> possibly other stuff in the future). >> >> Looking forward to hearing what you have to say. > > no tree. no git. :) As mentioned by others in this thread, it's a branch, not a different repo. Why would I put it in a different repo?! :) -- Tom. ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
