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]<javascript:> > > 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]<javascript:> >> > 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]<javascript:> >>> > 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]<javascript:> >>>> > 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]<javascript:> >>>>> > 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]<javascript:> >>>>>> > 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/ >>>>>>>>>> emscripten/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.
