[Wasm64] Initial work for get parts of embind working #17239
Conversation
| @@ -439,6 +439,7 @@ var LibraryEmbind = { | |||
|
|
|||
| _embind_register_bool__deps: [ | |||
| '$getShiftFromSize', '$readLatin1String', '$registerType'], | |||
| _embind_register_bool__sig: 'vpppii', | |||
There was a problem hiding this comment.
Here's where I start asking dumb basic questions about JS libs.
what happens when there's no signature on a JS lib function? What does adding them here accomplish?
There was a problem hiding this comment.
There are a couple of different uses for these signatures.
In this case we need the signature so that we can generate automatic BigInt<->Number conversion wrapper at the boundary. The p here means pointer and is used for pointer/size_t things that we know assume won't exceed 53-bits..
There was a problem hiding this comment.
Without these the JS code recieves BitInt values when running with MEMORY64.. which most of our JS code is not setup to receive.
| @@ -372,18 +379,18 @@ var LibraryEmVal = { | |||
| return Emval.toHandle(rv); | |||
| }, | |||
|
|
|||
| _emval_lookupTypes__deps: ['$requireRegisteredType'], | |||
| _emval_lookupTypes: function(argCount, argTypes) { | |||
| $emval_lookupTypes__deps: ['$requireRegisteredType'], | |||
There was a problem hiding this comment.
what's the difference between the $-prefixed and the _-prefixed function names?
There was a problem hiding this comment.
$-prefixed functions are JS-only, and not visible to the native code/linker. When we have a function like this that take a JS object, my policy is always to $-prefix it.
| #endif | ||
| // Use uint32_t for pointer values. This limits us, for now, to 32-bit | ||
| // address ranges even on wasm64. This is enforced by assertions below. | ||
| // TODO(sbc): Allow full 64-bit address range here under wasm64, most |
There was a problem hiding this comment.
I assume if we updated this to 64-bit, we'd still want to use 53-bit ranges on the JS side though?
There was a problem hiding this comment.
Yes, I think they are separate concerns.
| abort(); | ||
| #endif | ||
| uintptr_t short_ptr = reinterpret_cast<uintptr_t>(wt); | ||
| assert(short_ptr <= UINT32_MAX); |
There was a problem hiding this comment.
is this assert going to get compiled out in release builds? Should we maybe make it a "real" error, or is there some other code that will help the user if they happen to end up with a pointer outside this range?
There was a problem hiding this comment.
Its only going to fire for users of MEMORY64 + embind... which is hyper experiential config anyway, so I'm not too worried.
|
Great work btw! |
No description provided.