FFI comparible for emscripten/make APIs public

[bram-nijenkamp]

Hi All,

Version of emscripten/emsdk:
Docker emsdk:
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.47 (431685f)

We have been using your API in a not so nice way I'll admit. But we use some internals to dynamically call JS functions. It is a cross-platform project in which on windows we use libffi and here we use this as a comparison. My problem was/is that val doesn't have it's _em_call en EM_VAL constructors public causing me to resort to these internals in the first place.

Now up until now this has worked great, however as of 3.1.47 you guys did something to val causing it to align to 8 bytes instead of pointer 4 on wasm32. As such the current way does not work. I have tried some more hacky stuff with offsets to fix it but to no affail.

As such I have come here on my knees to ask you guys to please make these APIs public or an abstraction on it to allow this dynamic calling?
Or should you have a better solution available.

Any other explanation I'll be able to provide as the snippet is off course rather small...

Sincerely,
FrozenSource

[sbc100]

@RReverser who knows more about EM_VAL that I do.

I can't see anything about EM_VAL that changed in 3.1.47.. EM_VAL is just a pointer type right? So it should always have pointer size and alignment. emscripten::val did change though since we added a thread handle there: #20344 . I suspect that what is effecting you?

(BTW, when you share code snippets is much better for use if you can do it in the form of text rather than images. Images cannot be copied or searched).

[RReverser]

So it should always have pointer size and alignment. emscripten::val did change though since we added a thread handle there: #20344 . I suspect that what is effecting you?

Yeah looks like they're casting emscripten::val* / relying on its layout in the example above?

We have been using your API in a not so nice way I'll admit. But we use some internals to dynamically call JS functions. It is a cross-platform project in which on windows we use libffi and here we use this as a comparison. My problem was/is that val doesn't have it's _em_call en EM_VAL constructors public causing me to resort to these internals in the first place.

Hmm yeah please don't rely on internals - we are likely to change those a lot, as evidenced above, especially in the nearest time. emscripten::val is the public API for this stuff.

[RReverser]

But we use some internals to dynamically call JS functions.

emscripten::val already calls JS functions dynamically by itself. Can you maybe show example of what you're trying to do and I could show how to do that without touching internals?

[RReverser]

It sounds / seems like you want to call JS functions with dynamic list of arguments? If so, you should use JS .apply on the val representing the function.

// create array for dynamic arguments
val args = val::array();
// populate that array
for (/* ... your input args ... */) {
  args.call<void>("push", yourDynamicArgument());
}
// get the function
val func = /* function you want to call */;
// call `.apply` on that function with empty `val` (`undefined`) for context and the array of arguments
val result = func.call<val>("apply", val(), args);

[bram-nijenkamp]

Off course I want to get rid of using your internals. But as opposed to the sample above the _em_call function this one is compiled based on templates.

I work on a production programming language which we try to port to webassembly and we’d love to have this feature (calling JS). But it would require complete dynamic calling like we’ve done up till now.

You see we don’t know what the end programmer’s function definition is.

[RReverser]

But as opposed to the sample above the _em_call function this one is compiled based on templates.

It's not, it can accommodate any dynamic number of args. It doesn't matter how you add them to the array.

[RReverser]

Judging from your snippet, you already populate types and args vectors somewhere before the provided code; just change that place to populate args from my example instead.

If you are still running into problems, it might be helpful if you posted the whole function.

[bram-nijenkamp]

Let me rephrase the variable types and references would be build up in the template. In this specific example I'd have to build a switch case in that for loop and push them in that way. What I liked so much about the _em_call was that I only needed a type lookup table and memcpy to a em_wtype array. Which makes it a whole lot dynamic.

Any way you'd be willing to make a public version of em_call returning a emscripten::val?

[bram-nijenkamp]

    using em_type_id = emscripten::internal::TYPEID;
    using em_wtype = emscripten::internal::GenericWireType;

    constexpr std::array<em_type_id, 13> type_lookup {
        emscripten::internal::TypeID<void>::get(), emscripten::internal::TypeID<int8_t>::get(),
            emscripten::internal::TypeID<uint8_t>::get(), emscripten::internal::TypeID<int16_t>::get(),
            emscripten::internal::TypeID<uint16_t>::get(), emscripten::internal::TypeID<int32_t>::get(),
            emscripten::internal::TypeID<uint32_t>::get(), emscripten::internal::TypeID<int64_t>::get(),
            emscripten::internal::TypeID<uint64_t>::get(), emscripten::internal::TypeID<float_t>::get(),
            emscripten::internal::TypeID<double_t>::get(),
#if defined(COMP_ENV64)
            emscripten::internal::TypeID<int64_t>::get(), emscripten::internal::TypeID<std::string>::get()
#else
            emscripten::internal::TypeID<int32_t>::get(), emscripten::internal::TypeID<std::string>::get()
#endif
    };

    COMP_THREAD_LOCAL std::array<em_type_id, ffi::max_external_function_args> types;
    COMP_THREAD_LOCAL std::array<em_wtype, ffi::max_external_function_args> args;

    COMP_THREAD_LOCAL size_t arg_index;
    COMP_THREAD_LOCAL size_t arg_count;

    COMP_THREAD_LOCAL func_t func;

    error_t call_initialize(func_t f, size_t argn, type_t rtype) {
        if (argn > ffi::max_external_function_args) {
            return error_t::TOO_MANY_ARGS;
        }
        if (!is_valid_type(rtype)) {
            return error_t::INVALID_TYPE;
        }
        arg_index = 0;
        arg_count = argn;
        func = f;

        return error_t::OK;
    }

    error_t call_push_arg(type_t type, void* arg) {
        if (!is_valid_type(type)) {
            return error_t::INVALID_TYPE;
        }

        types[arg_index] = type_lookup[(size_t) type];
        std::memcpy(&args[arg_index], arg, 8);
        arg_index++;
        return error_t::OK;
    }

    error_t call_push_string(const void* begin, const void* end) {
        types[arg_index] = emscripten::internal::TypeID<std::string>::get();
        args[arg_index++].w[0].p =
            reinterpret_cast<void*>(emscripten::internal::BindingType<std::string>::toWireType({ (const char*) begin, (const char*) end }));

        return error_t::OK;
    }

    error_t call_push_wstring(const void* begin, const void* end) {
        types[arg_index] = emscripten::internal::TypeID<std::u16string>::get();
        args[arg_index++].w[0].p = reinterpret_cast<void*>(
            emscripten::internal::BindingType<std::u16string>::toWireType({ (const char16_t*) begin, (const char16_t*) end }));
        return error_t::OK;
    }

    error_t call_finalize(void* ret_val) {
        if (arg_index != arg_count) {
            return error_t::INVALID_ARG_COUNT;
        }

        auto* f_ptr_p = (emscripten::val*) &func;
        emscripten::EM_VAL retval_handle = _emval_call((*f_ptr_p).as_handle(), arg_count, types.data(), args.data());

        if (ret_val) {
            auto* val_p = (emscripten::val*) &retval_handle;

            if (val_p->isNull()) {
                *((int64_t*) ret_val) = 0;
            } else if (val_p->isUndefined()) {
                *((int64_t*) ret_val) = 0;
            } else if (val_p->isTrue()) {
                *((bool*) ret_val) = val_p->as<bool>();
            } else if (val_p->isFalse()) {
                *((bool*) ret_val) = val_p->as<bool>();
            } else if (val_p->isNumber()) {
                *((int64_t*) ret_val) = val_p->as<int64_t>();
            } else if (val_p->isString()) {
                s_ret_val = val_p->as<std::string>();
                *((const char**) ret_val) = s_ret_val.c_str();
            } else if (val_p->isArray()) {
                UNREACHABLE_EX("unsupported for now.");
            }
        }

        emscripten::internal::_emval_decref(retval_handle);

        return error_t::OK;
    }

[RReverser]

In this specific example I'd have to build a switch case in that for loop and push them in that way.

No, you don't need a switch, just pass them to push directly. val takes care of the conversions.

Please try to implement it like in my snippet above and let me know if you run into issues.

Any way you'd be willing to make a public version of em_call returning a emscripten::val?

Very unlikely, as I said, those are internal implementation details and really shouldn't be used. I'm working on a refactoring that will likely remove _emval_call altogether.

[bram-nijenkamp]

You prop missed my code report, but as you can see we don't have access to the native type so to say. Now you might say just refactor 4 different ffi api-platforms worth of code but I think the public version of emval_call might be a great addition.

I'd like to stay with your latest branches if possible and doing this through public channels.

[RReverser]

You prop missed my code report, but as you can see we don't have access to the native type so to say.

Ah yeah then you'll probably need to replace your type_lookup table with a switch like you said. It would have same number of branches as your current array, so either way, by using public API + .apply you should end up with smaller and simpler code.

These functions are called internal:: for a reason - as in, they are internal to Emscripten and the only reason they are not properly private and hidden from the user is because our Embind implementation lives in headers. For all intents and purposes they truly are private and can be changed at any moment.

the public version of emval_call might be a great addition

That's exactly what .apply is for. Except it avoids relying on Type IDs too, which are also internal implementation detail and can be removed at any time.

[bram-nijenkamp]

obviously I agree with your comments about the internal:: namespace.
But I see no reason whatsoever to get rid of things which make a framework such as emscripten less dynamic and in some case easy to use.
Templating is nice and all but sometimes you just need a c-like api to do your stuff best.
I guess it's just agree to disagree in this case and we'll see what we'll do.

[RReverser]

But I see no reason whatsoever to get rid of things which make a framework such as emscripten less dynamic and in some case easy to use.

You might not see it, but it's important for performance of the public API and being able to use it in more places.

val represents JavaScript values, it can't really get more dynamic than that. That's why I'm recommending using val directly together with corresponding JS APIs - your code will be simpler, faster, and yet equally dynamic at the same time. What's not to like (except for having to rewrite a little bit of code once to move away from APIs that weren't meant to be used in the first place).

You even already have correct switch using the val's APIs for the return value - the one for arguments can be pretty much copy-pasted from that, and just invert the direction so that it reads vals instead of writing them.

[RReverser]

We have been using your API in a not so nice way I'll admit. But we use some internals to dynamically call JS functions. It is a cross-platform project in which on windows we use libffi and here we use this as a comparison.

Btw you say you're using libffi on other platforms. Just in case - you know there is a port of libffi for Emscripten too? https://github.com/hoodmane/libffi-emscripten

If that works for you, you might not even need to maintain your own implementation and just compile with libffi on all platforms.