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). > 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 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... :/ > 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. :) > -- > Tom. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
