Thanks for doing this work Chad! I have started an open source port of liquid fun(C++ physics library based on box2D) using embind. I was terrified to read embind might be going away.
>From a perf standpoint, is it better to just wrap the whole api in C, and then use normal emcc + handwritten js bindings? On Monday, March 31, 2014 12:10:42 PM UTC-7, Chad Austin wrote: > > Just so you know, you'll have to modify emcc to disable the errors about > using embind with fastcomp/asm.js. > > Also, only the emscripten::val type works for now. > > > > On Mon, Mar 31, 2014 at 1:19 AM, Warren Seine <[email protected]<javascript:> > > wrote: > >> Thanks a lot Chad, I will test it this week. >> >> >> On Saturday, March 29, 2014 8:05:46 AM UTC+1, Chad Austin wrote: >> >>> I just submitted a pull request that makes emscripten::val compatible >>> with fastcomp/asm.js. >>> >>> https://github.com/kripken/emscripten/pull/2264 >>> >>> The technique used to achieve portability across both versions of the >>> compiler is to use variadic templates to generate the varargs data, rather >>> than relying on the compiler to do it. https://github.com/imvu/ >>> emscripten/commit/aa05c2ee438ed1904ef90ebaebe3193dccd7f222 >>> >>> Next I will see about making the rest of embind compatible with >>> fastcomp/asm.js. >>> >>> >>> >>> On Mon, Mar 24, 2014 at 10:59 AM, Alon Zakai <[email protected]> wrote: >>> >>>> This is only in varargs, and due to the pnacl varargs pass. Fastcomp >>>> does align doubles inside structures properly and so forth. >>>> >>>> Yes, this affects all floats in varargs, good point. Should be fixed. >>>> >>>> - Alon >>>> >>>> >>>> >>>> On Mon, Mar 24, 2014 at 10:15 AM, Chad Austin <[email protected]> wrote: >>>> >>>>> Oh, in fastcomp, it's always 32-bit alignment only? I guess I assumed >>>>> doubles would still be aligned. Interesting. >>>>> >>>>> The C++ (and C?) standard specifies that floats are converted to >>>>> doubles in varargs, so 32-bit alignment could affect all floats and >>>>> doubles. >>>>> >>>>> I just realized I can work around the code generation differences here >>>>> by doing my own packing into a void* args pointer with a variadic >>>>> template. I may try that next, as it makes embind more portable across >>>>> code generation modes. >>>>> >>>>> >>>>> >>>>> On Mon, Mar 24, 2014 at 7:55 AM, Alon Zakai <[email protected]> wrote: >>>>> >>>>>> In library.js we ifdef on that in a few places, see formatString for >>>>>> example. Yes, this changes by compilation mode. We used to do 64-bit >>>>>> alignment all the time, but in fastcomp we use the pnacl varargs >>>>>> lowering >>>>>> pass, which does only 32-bit alignment. We should fix that eventually as >>>>>> it >>>>>> means doubles are slower in varargs. >>>>>> >>>>>> - Alon >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Mar 24, 2014 at 2:59 AM, Chad Austin <[email protected]> wrote: >>>>>> >>>>>>> I made substantial progress on getting emscripten::val to work in >>>>>>> asm.js tonight. Just emscripten::val, not any of the function or class >>>>>>> binding stuff. >>>>>>> >>>>>>> https://github.com/imvu/emscripten/commits/master >>>>>>> >>>>>>> It no longer uses reinterpret_cast on function pointers. Instead it >>>>>>> uses varargs. >>>>>>> >>>>>>> Unfortunately, my demo doesn't quite run yet. The old compiler had >>>>>>> 8-byte alignment on varargs, but the new compiler appears to usually >>>>>>> fit >>>>>>> integers in 4 bytes. I'll need to find some way to switch off of >>>>>>> whether >>>>>>> asm.js is enabled in the embind JavaScript. >>>>>>> >>>>>>> Alon: do you know if there's an easy way to detect whether fastcomp >>>>>>> or asm.js is enabled at runtime? >>>>>>> >>>>>>> Also, what _is_ the vararg convention for fastcomp/asm.js? Is it >>>>>>> the same as asm.js in the old compiler? Or is fastcomp the new factor >>>>>>> here? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Mar 23, 2014 at 12:48 AM, Chad Austin <[email protected]>wrote: >>>>>>> >>>>>>>> I found some time and got a few bits of embind working: >>>>>>>> >>>>>>>> https://github.com/imvu/emscripten/commit/ >>>>>>>> afc59d1e331c445a5762f6a5751b86740b1ebbeb >>>>>>>> https://github.com/imvu/emscripten/commit/ >>>>>>>> 228b4fc349f1cdf592821d988240e7d9543462be >>>>>>>> >>>>>>>> When I get a minimal demo up and running in fastcomp/asm.js, I'll >>>>>>>> submit a pull request. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Mar 17, 2014 at 3:11 PM, Dean Elhard <[email protected]>wrote: >>>>>>>> >>>>>>>>> I would be interested in helping, although I haven't looked at how >>>>>>>>> it works, so I am not sure what exactly is involved... >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wednesday, March 5, 2014 2:33:34 AM UTC-7, Chad Austin wrote: >>>>>>>>> >>>>>>>>>> True! We do want to use fastcomp but wasn't sure the advantages >>>>>>>>>> outweighed the embind porting work. >>>>>>>>>> >>>>>>>>>> However, because Dean asked, I sat down and took a look tonight, >>>>>>>>>> and got a few functions working. Most of the work is in getting rid >>>>>>>>>> of the >>>>>>>>>> function pointer casts, but it seems quite straightforward. >>>>>>>>>> >>>>>>>>>> I'll poke away and send pull requests when I have them... If >>>>>>>>>> anyone wants to help, let me know. :) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Mar 4, 2014 at 8:27 PM, Alon Zakai <[email protected]>wrote: >>>>>>>>>> >>>>>>>>>>> Note that fastcomp supports a growable heap in asm.js mode. It >>>>>>>>>>> will not validate as asm.js, but should still get much of the >>>>>>>>>>> speedups from >>>>>>>>>>> it, just without guarantees and probably not all of them. >>>>>>>>>>> >>>>>>>>>>> - Alon >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Mar 4, 2014 at 2:46 PM, Chad Austin <[email protected]>wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Dean, >>>>>>>>>>>> >>>>>>>>>>>> We should port embind to asm.js! It's certainly a bit of work, >>>>>>>>>>>> but probably not too hard. It's really just that nobody's done >>>>>>>>>>>> the work >>>>>>>>>>>> yet. Since IMVU, my employer, can't use asm.js until it supports >>>>>>>>>>>> a >>>>>>>>>>>> growable heap (and perhaps closure compiler), we aren't terribly >>>>>>>>>>>> motivated >>>>>>>>>>>> to do the work. >>>>>>>>>>>> >>>>>>>>>>>> That said, part of me just wants to bite the bullet and do the >>>>>>>>>>>> conversion myself if I can find the time. :) >>>>>>>>>>>> >>>>>>>>>>>> In case someone else wants to take a crack at it, here is what >>>>>>>>>>>> I know: >>>>>>>>>>>> >>>>>>>>>>>> There are a couple places where embind uses reinterpret_cast on >>>>>>>>>>>> function pointers in order to pass more arguments than their >>>>>>>>>>>> prototypes >>>>>>>>>>>> specify. For example, see https://github.com/kripken/ems >>>>>>>>>>>> cripten/blob/master/system/include/emscripten/val.h#L67 >>>>>>>>>>>> >>>>>>>>>>>> Those functions need to be converted to varargs. (At the time, >>>>>>>>>>>> I think we were blocked on a varargs issue with the old LLVM, but >>>>>>>>>>>> that may >>>>>>>>>>>> not be an issue anymore.) >>>>>>>>>>>> >>>>>>>>>>>> The other issue is that embind relies on JavaScript being able >>>>>>>>>>>> to look up functions by indexing into FUNCTION_TABLE[x]. asm.js >>>>>>>>>>>> doesn't >>>>>>>>>>>> have a single function table: it has a whole bunch of function >>>>>>>>>>>> tables, one >>>>>>>>>>>> for each possible type signature. >>>>>>>>>>>> >>>>>>>>>>>> Thus, on the C++ side, we need a way to take a C++ signature >>>>>>>>>>>> (like float(const void*, int&)) and turn that into a string >>>>>>>>>>>> ("fii") that we >>>>>>>>>>>> can use to select one of the function tables on the embind side. >>>>>>>>>>>> Embind >>>>>>>>>>>> would also need the compiler to output a table from signature to >>>>>>>>>>>> the >>>>>>>>>>>> appropriate function table. The compiler-generated glue would >>>>>>>>>>>> look >>>>>>>>>>>> something like: >>>>>>>>>>>> >>>>>>>>>>>> var FUNCTION_TABLES = { >>>>>>>>>>>> vi: FUNCTION_TABLE_vv, >>>>>>>>>>>> fii: FUNCTION_TABLE_fii, >>>>>>>>>>>> ... >>>>>>>>>>>> }; >>>>>>>>>>>> >>>>>>>>>>>> I *think* that if we had those two things, we could make >>>>>>>>>>>> embind work with asm.js. >>>>>>>>>>>> >>>>>>>>>>>> *waves hands a bit* :) >>>>>>>>>>>> >>>>>>>>>>>> Hope that's helpful, >>>>>>>>>>>> Chad >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Mar 4, 2014 at 2:28 PM, Dean Elhard <[email protected] >>>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Since 1.13.0 is moving to the fastcomp compiler, which only >>>>>>>>>>>>> supports asm.js, and embind doesn't work with asm.js, it seems >>>>>>>>>>>>> that anyone >>>>>>>>>>>>> relying on embind is being left behind. >>>>>>>>>>>>> >>>>>>>>>>>>> The issues I see on github regarding embind and asm.js are old >>>>>>>>>>>>> and inactive, and indicate no plans to make embind work with >>>>>>>>>>>>> asm.js any >>>>>>>>>>>>> time soon. >>>>>>>>>>>>> >>>>>>>>>>>>> Any comment on the future of embind (if any), or what will >>>>>>>>>>>>> replace it? >>>>>>>>>>>>> >>>>>>>>>>>> -- >>> Chad Austin >>> Technical Director, IMVU >>> http://engineering.imvu.com <http://www.imvu.com/members/Chad/> >>> http://chadaustin.me >>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Chad Austin > Technical Director, IMVU > http://engineering.imvu.com <http://www.imvu.com/members/Chad/> > http://chadaustin.me > > > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
