* fix: remove SIMD prefix handling from interpreter and update opcode definitions
* test: add case for classic interpreter handling of unsupported SIMD opcodes
to run product-mini/platforms/zephyr/simple and
product-mini/platforms/zephyr/user-mode
Construct a T2 (star topology) for the current smoke test. This is not the
final topology, and we may modify it once we determine the optimal
configuration.
do not return __WASI_ERRNO_xxx error code where 0/-1 is more appropriate.
most of them were not harmful because the value of
__WASI_ERRNO_SUCCESS is 0.
the one with __WASI_ERRNO_NOPROTOOPT in socket() is
a user-visible bug.
tested with wamr-wasi-extensions/samples/socket-tcp-udp.
cf. https://github.com/bytecodealliance/wasm-micro-runtime/issues/4474
some getaddrinfo implementations sometimes return results with
ai_protocol=0.
cf. https://github.com/apache/nuttx/issues/16693
standard-wise, i couldn't find anything about ai_protocol in
susv4-2018 except the following text:
> The fields ai_family, ai_socktype, and ai_protocol shall be usable
> as the arguments to the socket() function to create a socket suitable
> for use with the returned address.
because ai_protocol is usually merely used to feed socket() and
socket() usually accepts 0, it's probably standard-wise ok for
getaddrinfo to return ai_protocol=0.
the major implementations of getaddrinfo (eg. kame) seem to return
specific values like ai_protocol=IPPROTO_TCP though.
anyway, for the purpose of this function, there is little point to
be strict on the host getaddrinfo behavior. this commit just relaxes
the check to be friendly to those getaddrinfo implementations.
* introduce wasm_runtime_instantiate_ex2
at this point, just a slightly inefficiant functionality
equivalent of wasm_runtime_instantiate_ex.
however, unlike wasm_runtime_instantiate_ex, this one is designed
to be extendable without breaking the user-visible ABI.
because the definition of InstantiationArgs2 is not exposed to
users, we can safely add new members to it.
this commit also makes wasm_runtime_instantiate_ex a wrapper
of wasm_runtime_instantiate_ex2.
if this goes well, maybe it's a good idea to apply a similar
pattern to RuntimeInitArgs, LoadArgs, SharedHeapInitArgs, etc.
i started with InstantiationArgs just because i happen to have
a need to extend it for wasi-nn.
cf.
https://github.com/bytecodealliance/wasm-micro-runtime/issues/4364https://github.com/bytecodealliance/wasm-micro-runtime/issues/4331
* product-mini/platforms/posix: use wasm_runtime_instantiate_ex2
as tested by core/iwasm/libraries/wasi-nn/test/test_tensorflow.c,
the legacy "wasi_nn" abi uses the number of fp32 for get_output.
because these backends don't implement the abi, bail out explicitly
in build time.
cf.
https://github.com/bytecodealliance/wasm-micro-runtime/issues/4376
christoph
