Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support tuple return type (multi-value feature) #156

Closed
brew0722 opened this issue Feb 23, 2022 · 3 comments
Closed

Support tuple return type (multi-value feature) #156

brew0722 opened this issue Feb 23, 2022 · 3 comments
Assignees
Labels
dynamic_link relate the dynamic link call feature enhancement New feature or request

Comments

@brew0722
Copy link
Contributor

brew0722 commented Feb 23, 2022

Problem

When compiling a tuple return function as shown below, wasm function is created to be passed as a param.
rust: fn return_tuple() -> (u64, u128)
WAT: (func $return_tuple (type $t6) (param $p0 i32)

A single return is passed as result like this:
rust: fn return_single() -> u64
WAT: (func $stub_return_single (type $t12) (result i32)

If the tuple return is passed as a single param, it is impossible to identify it on the vm host side and copy the region.

Solution

https://hacks.mozilla.org/2019/11/multi-value-all-the-wasm/

This can be solved using wasm's multi-value feature.
RUSTFLAGS="-C target-feature=+multivalue"
We can expect to create a multi value return like this:
WAT: func $return_tuple (type $t6) (result i32 i32)

Problem of Solution

There are two problems.

  1. The above rustc feature is not yet stable. Experimentally compiling the sample contract is failing.
    .../release/deps/libuuid-462c11271c01b650.rmeta -C target-feature=+multivalue`` (signal: 11, SIGSEGV: invalid memory reference)
  2. Cannot support yet multi-value feature by Singlepass of Wasmer
    https://github.com/wasmerio/wasmer/blob/9291c27941f15a2446be603a5f64f716bf321361/lib/compiler-singlepass/src/compiler.rs#L80
brew0722 pushed a commit to brew0722/cosmwasm that referenced this issue Feb 23, 2022
@brew0722 brew0722 added dynamic_link relate the dynamic link call feature enhancement New feature or request labels Feb 23, 2022
@zemyblue
Copy link
Member

Please check other development language. For example C/C++

brew0722 pushed a commit to brew0722/cosmwasm that referenced this issue Mar 7, 2022
brew0722 pushed a commit to brew0722/cosmwasm that referenced this issue Mar 18, 2022
brew0722 pushed a commit that referenced this issue Mar 31, 2022
* feat: add #[callable_point] proc macro

* feat: add #[dynamic_link] proc macro

* fix: publiclize the memory module

using in #[callable_point] and #[dynamic_link]

* feat: add re-exports #[callable_point] and #[dynamic_link]

* feat: make tuple return by #[callable_point] and #[dynamic_link]

* feat: add copies region of args and return between env

The actual copy calls are executed by wasmvm.

* fix: disable return the tuple type

#156

* refactor: improve error handling with proc_macro_error

* feat: update sample contract for dynamic_link

* test: add unit test for copy_region_vals_between_env

* test: add integration test for callable_point macro

proc_macro cannot do normal unit tests.
Instead, it is replaced by the contract's integration test.

* test: add integration test for dynamic_link macro

proc_macro cannot do normal unit tests.
Instead, it is replaced by the contract's integration test.

* fix: unlimit the target_arch of memory module

When running the test with dynamic_link proc_macro,
it should be able to compile the memory module on other architectures as well.

* chore: cargo fmt

* chore: update cargo.lock for contracts

* fix: fix maximum size

* chore: cargo clippy

* test: add module name test condition for dynamic_link macro

* chore: fix reverted unused warnings in the contracts

* chore: fix typo

* chore: remove unnecessary prefix

* refactor: improve abort message

* refactor: change to use quote! and proc_macro2

proc_macro2 allows the implementation of separate modules.

* chore: update cargo.lock

* chore: disable clippy warning for abort_by!

* fix: add disallowed type by parameter

see: #152

* chore:cargo fmt

* chore: avoid false-positive of clippy

* chore: again avoid clippy

* chore: fix typo
@brew0722 brew0722 self-assigned this May 2, 2022
@brew0722
Copy link
Contributor Author

brew0722 commented May 19, 2022

This issue was reviewed before the introduction of proc macros #[callable_point] and #[dynamic_link], when primitive types were delivered as they are.

But now it is passed through serialization by the above proc macro. Therefore, it can be expected that a tuple can also be passed as a single serialized data.

It is necessary to check whether the tuple type is available by serialization.

@loloicci
Copy link
Contributor

closed via #195

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dynamic_link relate the dynamic link call feature enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants