Give native support to host function imports
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- wasm
- Ambito
- compilers
Direzione di ricerca
Inizia esaminando l’approccio dei moduli host nella pull request indicata e la definizione di embedding di KEwasm. Poi traccia il modo in cui gli import e le istruzioni di chiamata a funzione sono rappresentati nella semantica di Wasm. Il lavoro sarà completato quando i moduli host e le chiamate host saranno rappresentati nativamente e gli embedding potranno dichiarare i propri moduli host e le proprie regole senza moduli wrapper.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
The current approach to host functions is to introduce a Wasm module to simulate it, and adding special function call instructions to it. See this file:
https://github.com/runtimeverification/polkadot-verification/pull/103/files/9a535a2332aa82ae15cef0c54bec7c32ed743f6a#diff-0ca3b001e51794c799c189d2e70e6aa0
I believe we can improve on that method a bit. As it stands, we either need to write a Wasm host module the way the script above does (which is frail), or write a K definition of the module as in KEwasm.
Instead of declaring a new instruction for all host functions and wrapping the host functions in a module, we could extend the Wasm semantics, by having each embedder specify which modules should be considered host modules (in this case "env", in the Ewasm case "ethereum"), and adding rules for them:
syntax Set ::= "#HostModules" [function]
syntax Instr ::= #hostCall(WasmSting, WasmString, TypeDecl)
rule (import MODNAME FUNCNAME (func OID:OptionalId T:TypeDecl)) => (func OID T (#hostCall(MODNAME, FUNCNAME, T))
requires MODNAME in #HostModules
Not saying this is something we should do now, necessarily, but it's something we should open an issue about,because it would make defining new embeddings easier. The concept of a host call would be native to the Wasm semantics, and each embedding would really only need to define the #HostModules set and each #hostCall it cares about. We could also assume any import from an undeclared module is a host function.
- Lingua principale
- WebAssembly
- Stelle
- 107
- Fork
- 26
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di runtimeverification/wasm-semantics
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 55/100
-
bug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 48/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
-
Improve tokenisation supportAperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
Tutte le issue di runtimeverification/wasm-semantics
Issue simili
-
bug P2
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 1 giorno
-
REPL and --show-tokens abort with "Token conversion not implemented yet" on .xor., byte and in outApertabug low priority tokenizer
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 76/100
WebAssembly/spec#2300 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
rescript-lang/rescript#8953 ·
I maintainer di solito rispondono entro 1 giorno