Stream: wit-bindgen

Topic: First take on ABI implementation for C++

Gordon Smith (Mar 19 2024 at 13:15):

@Christof Petig Finally had some time over the weekend to implement the ABI in C++. This is only my first iteration and I still have most of the complex types to do (have most of the functions done, just not fully tied together)

https://github.com/GordonSmith/component-model-cpp

The ABI doesn't have any dependencies on specific runtimes (as you would expect), but wiring it into Wasmtime looks like: https://github.com/GordonSmith/component-model-cpp/blob/master/test/wasmtime.cpp

Be gentle it has been nearly a decade since I did any serious c++ work!

Christof Petig (Mar 19 2024 at 22:37):

@Gordon Smith This looks interesting, but to be honest I don't understand the purpose of the code. Is it to use the canonical ABI without WIT? If so, how would the other side look like? Would you think that bindgen should target this as a lifting and lowering library? I guess you target the host side :thinking:

Side note: "Be gentle it has been nearly a decade since I did any serious c++ work!"
I think you are really doing fine (seeing the use of <span> which is C++20) and you might easily write better C++ code than I do (I spent too much time on pre-C++11 compilers and then jumped into Rust coding).

Gordon Smith (Mar 20 2024 at 08:05):

My primary use case is to embed wasm components inside a domain specific language (a big data engine) as such we will publish a WIT interface to expose host capabilities.
The guest author can also expose functions to the host, but they need to be prototyped in the domain specific language, which ideally would be generated via WIT, but hand crafting them is probably more practical in the short term...

My secondary goal (as you guessed) is to suggest that your WIT -> C++ host generation would target this API with the following benefits:

1. The code generation should be a lot simpler as the ABI supports all the data types from WIT, so should almost be a straight mapping.
2. The generated code would not be tied to any specific web assembly runtime!!!

Supporting specific runtimes would then be a relatively trivial exercise (getting a ref to the memory and mapping the lowered values for that runtime).

My TODO list is:

1. Finish support for all the data types
2. Make the final API more C++ friendly (have top level support for sting, string<WCHAR> vector map etc...).

Last updated: Oct 23 2024 at 20:03 UTC