Yep, being able to read/write that entire memory state, especially if it contains the IP, should be quite good. 
OvermindDL1
1
alexdovzhanyn
Just released v0.8.1, where this feature and others were added. Here’s a fun blog post on using the new Memory API within a WebAssembly tic tac toe game
2
OvermindDL1
board = WaspVM.HostFunction.API.get_memory(ctx, "game_mem", 0, 9) Oooo awesome!
I like the post, easy to read, follow, and understand.
As for WaspVM.HostFunction.API.get_memory/4 does that include the instruction pointer and all as well? I.E. if WASM calls ‘into’ an elixir function, can that elixir function serialize up the whole state then pick up again where it left off (assuming no other elixir functions are on the wasm stack, and probably some argument indicating whether it was just loaded or not)?
This variable is defined by the
defhostmacro, and is solely used as a reference that’s passed into the HostFunction API.
As for this, I’m really not a fan of magic variables, why not have the user prepend it to all defhost argument lists so it is explicitly passed in, thus:
defhost get_move_for_player(player) do
defhost draw_board do ... end
And so forth should actually be written like:
defhost get_move_for_player(vmctx, player) do
defhost draw_board(vmctx) do ... end
I always try to remember the Python tenant: Explicit is Better than Implicit
Also, does this mean you can’t call the function from outside the WaspVM interpreter? Like what would you pass in then, the PID like this?
def run_game do
# Start a fresh VM instance
{:ok, pid} = WaspVM.start()
WaspVM.load_file(pid, "priv/wasm/tic_tac_toe.wasm", imports)
{:ok, gas, result} = WaspVM.execute(pid, "play")
WaspVM.HostFunction.API.get_memory(pid, "game_mem", 0, 9)
end
Also, the calls return the gas, but is there a way to set a limit on how much gas is allowed to be used in a call before it just exceptions out or serializes/pauses its state or so for later resumption?
3
alexdovzhanyn
Thanks! Appreciate the feedback tons
We’ve decided not to expose internal VM state at all – so instruction pointers won’t be available. Things can easily get messy when allowing people to poke around inside the VM – and it should be possible to do most things by serializing / deserializing memory. If we were to expose instruction pointers and the call stack this would be akin to the BEAM providing functionality to do the same at runtime – although useful in some cases, potentially easily destructive.
This allows for messy programming – and is also something that falls outside of the WebAssembly spec. For example: if you have an elixir program that can run and do some work, and then could be stopped, serialized, and restarted by passing state back to the BEAM, certain safety checks such as if the program is in the middle of writing to a file would be bypassed (e.g. it’s dangerous to resume the execution of a function halfway through).
In most cases, I agree that magic variables aren’t the way to go, however in this case I feel as though it makes sense – host function heads defined by defhost need to strictly resemble the function heads that they’ll be exposed as in the WebAssembly module. It could easily get confusing when you have a function like
defhost get_move_for_player(vmctx. player) do ... end
that you need to interface with in WebAssembly like
(import "Module" "get_move_for_player" (func (param i32) (result i32)))
because the former has 2 params and the latter has only 1. Plug does the same thing with their conn variable in the router.
You can! The only thing is that you would need to use the functions defined in the VM itself WaspVM.get_memory/2 and WaspVM.update_memory/3, as it takes a reference to the VM directly, and then you can use WaspVM.Memory to interface with the memory. So the above code would be rewritten as
def run_game do
# Start a fresh VM instance
{:ok, pid} = WaspVM.start()
WaspVM.load_file(pid, "priv/wasm/tic_tac_toe.wasm", imports)
{:ok, gas, result} = WaspVM.execute(pid, "play")
# Retrieve an exported memory from the VM
mem = WaspVM.get_memory(pid, "game_mem")
# Read bytes from memory
WaspVM.Memory.get_at(mem, 0, 9)
end
Yep! you can do this by passing a gas_limit when calling WaspVM.execute:
WaspVM.execute(pid, "some_func", [], gas_limit: 100)
If the gas limit is reached, the program will interrupt and return an error.
1
OvermindDL1
Then what about adding it as an argument to the defhost? Like via:
defhost get_move_for_player(player), context: ctx do
...
end
That will just be a defhost definition like:
defmacro defhost(head, mappers \\ [], [do: body]) do
context_var = mappers[:context] || Macro.var(:ctx, nil)
# Then just unquote `context_var` where-ever its used now
end
That will support both the old implicit style as well as well as allowing someone to not just make it explicit but also name the variable whatever they want. This is a pattern I use for similar purposes.
Can move the options to before the head as well:
defhost [context: ctx], get_move_for_player(player) do
...
end
Whichever you think feels more natural (I’ve seen both forms pretty equally, having it in front means you require the [/] wrapping it though where having it at the end, before the do, means that you don’t).
In addition, both forms let you add more ‘mapping’ variables in the future with trivial ease if you ever need to. And if you think you don’t want to support the implicit forms (I recommend not to support them personally) then you can use that knowledge to generate more efficient code as well!
0
OvermindDL1
Except you can ‘pop’ the first one if it matches a pattern, like being named ctx or so, that is still awfully implicit though. ^.^;
Awesome!! ^.^
Great! Is there a way to not have it error but instead return a ‘continuation’? Perhaps something like:
case WaspVM.execute(pid, "some_func", [], gas_limit: 100) do
{:ok, return} -> return # this is a returned variable
{:continuation, cont} ->
cont.() # Can just call it again to run it with the same options
# Or perhaps make it take an argument list like `cont.([])` so you can do something like:
# cont.(gas_limit: 50)
# To change the certain specific options and pick up where it left off otherwise.
{:error, reason} -> throw reason # This is a returned hard error
end
Could just do one-shot continuations is fine, although if possible (maybe via an option if costly, though if memory is a binary it shouldn’t be as it’s copy-on-write, not read) then the continuation could wrap the entire interpreter state so it could be called again multiple times to continue from the save point that the continuation itself wraps (this is a pattern I did in a couple of interpreters I wrote in Elixir).
Also, instead of running the interpreter in another process, have you thought of having a state be passed in/out of everything (like the lua interpreter) so we can just run it in-process (we can always spawn a process if we need), that means it becomes trivial to do things like clone the existing state of the interpreter and all among other capabilities.
0
marcalchca
Hi,
At the Elixir Conf 2019 and in chats I find in 2019 I see a lot about WASM and Elixir/BEAM.
We are now approximately 7 - 9 months after most of the discussions I find. Sure a lot must have happened in between?
How far are we from compiling Elixir to be executed in the browser?
Since I’m taking steps to move to Elixir/Phoenix for PWA-development, the offline development is what I’m missing, so either LiveView can be used with a BEAM running in the browser (?) or we can simply compile Elixir (and LiveView?) to a binary format executed in the browser …
Thanks for helping me have realistic expectations about maturity and the road map …
Best regards
Marc
0
