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/
>>>>>>>> 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?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  --
>>>>>>>>> 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/groups/opt_out.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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/groups/opt_out.
>>>>>>>>
>>>>>>>
>>>>>>>  --
>>>>>>> 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/groups/opt_out.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> 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.
>>>
>>
>>  --
>> 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.
>

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

Reply via email to