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]> 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]. > 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.
