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.

Sign up for GitHub

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

Jump to bottom

Describe a primitive reactor ABI. #256

Merged
merged 3 commits into from
Apr 20, 2020
Merged

Describe a primitive reactor ABI. #256

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
f84b257
Describe a primitive reactor ABI.
sunfishcode Apr 13, 2020
50a8165
Mention that command and reactor kinds are mutually exclusive.
sunfishcode Apr 13, 2020
4cb1c73
Rename `_activate` to `_initialize`.
sunfishcode Apr 13, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 20 additions & 11 deletions design/application-abi.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,20 +12,29 @@ include.
Current Unstable ABI
--------------------

The current WASI unstable ABI specifies only two exports from a WASI
application:
There are two kinds of modules:

- `_start` - the program entry point
- `memory` - linear memory used by the program
- A *command* exports a function named `_start`, with no arguments and no return
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Partially off topic, but why not pass some configuration data to _start?

For example, the function could receive the command line args, the allowed paths, etc. These would be through interface types, of course.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, exactly. There are a lot of things we could do here, but we need interface types to do them well. The current argv/environ interfaces we have now aren't super amazing, and _start isn't a great name, and so on, but at the moment it all works well enough that it doesn't seem worth breaking compatibility until we have a big reason for it, like interface types.

values. Environments shall call this function once, after instantiating the
module and all of its dependencies. After this function exits, the instance
is considered terminated and no further use of any of its exports should be
permitted.

The `_start` export must be WebAssembly function and will be used as the program
entry point. This is the default name used by `lld` when linking WebAssembly
modules. The embedder is expected to call this function once the module is
instantiated.
- A *reactor* exports a function named `_initialize`, with no arguments and no
return values. Environments shall call this function once, after instantiating
the module and all of its dependencies. After this function exits, the instance
remains live, and its exports may be accessed.

Many of the current WASI unstable APIs require sharing of linear memory between
the application and the embedder. In order to use any such APIs the WASI module
is expected to export its linear memory under the name `memory`.
These kinds are mutually exclusive; implementations should report an error if
asked to instantiate a module containing exports which declare it to be of
multiple kinds.

Regardless of the kind, all programs accessing WASI APIs also export a linear
memory with the name `memory`. Pointers in WASI API calls are relative to this
memory's index space.
sbc100 marked this conversation as resolved.
Show resolved Hide resolved

In the future, as the underlying WebAssembly platform offers more features, we
we hope to eliminate the requirement to export all of linear memory.

Planned Stable ABI
------------------
Expand Down