You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You can use ``addFunction`` to return an integer value that represents a
616
-
function pointer. Passing that integer to C code then lets it call that value as
617
-
a function pointer, and the JavaScript function you sent to ``addFunction`` will
618
-
be called.
616
+
function pointer. Passing that integer to C code then lets it call that value
617
+
as a function pointer, and the JavaScript function you sent to ``addFunction``
618
+
will be called.
619
619
620
620
See `test_add_function in test/test_core.py`_ for an example.
621
621
622
622
You should build with ``-sALLOW_TABLE_GROWTH`` to allow new functions to be
623
623
added to the table. Otherwise by default the table has a fixed size.
624
624
625
-
.. note:: When using ``addFunction`` on LLVM Wasm backend, you need to provide
626
-
an additional second argument, a Wasm function signature string. Each
627
-
character within a signature string represents a type. The first character
628
-
represents the return type of a function, and remaining characters are for
629
-
parameter types.
625
+
When using ``addFunction`` with a JavaScript function, you need to provide
626
+
an additional second argument, a Wasm function signature string, explained
627
+
below. See `test/interop/test_add_function_post.js <https://github.com/emscripten-core/emscripten/blob/main/test/interop/test_add_function_post.js>`_ for an example.
628
+
629
+
630
+
.. _interacting-with-code-function-signatures:
631
+
632
+
Function Signatures
633
+
===================
634
+
635
+
The LLVM Wasm backend requires a Wasm function signature string when using
636
+
``addFunction`` and in JavaScript libraries. Each character within a signature
637
+
string represents a type. The first character represents the return type of a
638
+
function, and remaining characters are for parameter types.
630
639
631
640
- ``'v'``: void type
632
641
- ``'i'``: 32-bit integer type
633
-
- ``'j'``: 64-bit integer type (currently does not exist in JavaScript)
642
+
- ``'j'``: 64-bit integer type (see note below)
634
643
- ``'f'``: 32-bit float type
635
644
- ``'d'``: 64-bit float type
645
+
- ``'p'``: 32-bit or 64-bit pointer (MEMORY64)
646
+
647
+
For example, if you add a function that takes an integer and does not return
648
+
anything, the signature is ``'vi'``.
649
+
650
+
When ``'j'`` is used there are several ways in which the parameter value will
651
+
be passed to JavaScript. By default, the value will either be passed as a
652
+
single BigInt or a pair of JavaScript numbers (double) depending on whether
653
+
the ``WASM_BIGINT`` settings is enabled. In addition, if you only require 53
654
+
bits of precision you can add the ``__i53abi`` decorator, which will ignore
655
+
the upper bits and the value will be received as a single JavaScript number
656
+
(double). It cannot be used with ``addFunction``. Here is an example of a
657
+
library function that sets the size of a file using a 64-bit value passed as
658
+
a 53 bit (double) and returns an integer error code:
659
+
660
+
.. code-block:: c
661
+
662
+
extern "C" int _set_file_size(int handle, uint64_t size);
663
+
664
+
.. code-block:: javascript
636
665
637
-
For example, if you add a function that takes an integer and does not return
638
-
anything, you can do ``addFunction(your_function, 'vi');``. See
639
-
`test/interop/test_add_function_post.js <https://github.com/emscripten-core/emscripten/blob/main/test/interop/test_add_function_post.js>`_ for an example.
Using ``-sWASM_BIGINT`` when linking is an alternative method of handling
671
+
64-bit types in libraries. ```Number()``` may be needed on the JavaScript
672
+
side to convert it to a useable value. See `settings reference <https://emscripten.org/docs/tools_reference/settings_reference.html?highlight=environment#wasm-bigint>`_.
0 commit comments