complete related works, better abstract
This commit is contained in:
zapashcanon
parent
9d17cdfc60
commit
844a43708d
GPG Key ID:
8981C3C62D1D28F1
197
wasocaml.bib
Normal file
197
wasocaml.bib
Normal file
@ -0,0 +1,197 @@
|
||||
@article{KB83,
|
||||
title={Simple word problems in universal algebras},
|
||||
author={Knuth, Donald E and Bendix, Peter B},
|
||||
journal={Automation of Reasoning: 2: Classical Papers on Computational Logic 1967--1970},
|
||||
pages={342--376},
|
||||
year={1983},
|
||||
publisher={Springer}
|
||||
}
|
||||
|
||||
@inproceedings{Lat08,
|
||||
title={LLVM and Clang: Next generation compiler technology},
|
||||
author={Lattner, Chris},
|
||||
booktitle={The BSD conference},
|
||||
volume={5},
|
||||
pages={1--20},
|
||||
year={2008}
|
||||
}
|
||||
|
||||
@article{VB14,
|
||||
title={From bytecode to JavaScript: the Js\_of\_ocaml compiler},
|
||||
author={Vouillon, J{\'e}r{\^o}me and Balat, Vincent},
|
||||
journal={Software: Practice and Experience},
|
||||
volume={44},
|
||||
number={8},
|
||||
pages={951--972},
|
||||
year={2014},
|
||||
publisher={Wiley Online Library}
|
||||
}
|
||||
|
||||
@software{The14,
|
||||
title={{Emscripten}},
|
||||
author={{The Emscripten Authors}},
|
||||
url={https://github.com/emscripten-core/emscripten},
|
||||
year={2014}
|
||||
}
|
||||
|
||||
@software{Web15,
|
||||
title={{Binaryen}},
|
||||
author={{WebAssembly Community Group participants}},
|
||||
url={https://github.com/WebAssembly/binaryen},
|
||||
year={2015}
|
||||
}
|
||||
|
||||
@article{Hil+17,
|
||||
title={Continuation passing style for effect handlers},
|
||||
author={Hillerstr{\"o}m, Daniel and Lindley, Sam and Atkey, Robert and Sivaramakrishnan, KC},
|
||||
year={2017},
|
||||
publisher={Dagstuhl Publishing}
|
||||
}
|
||||
|
||||
@inproceedings{Haa+17,
|
||||
title={Bringing the web up to speed with WebAssembly},
|
||||
author={Haas, Andreas and Rossberg, Andreas and Schuff, Derek L and Titzer, Ben L and Holman, Michael and Gohman, Dan and Wagner, Luke and Zakai, Alon and Bastien, JF},
|
||||
booktitle={Proceedings of the 38th ACM SIGPLAN Conference on Programming Language Design and Implementation},
|
||||
pages={185--200},
|
||||
year={2017}
|
||||
}
|
||||
|
||||
@software{Mar17,
|
||||
title={{OCamlrun WebAssembly}},
|
||||
author={Markbåge, Sebastian},
|
||||
url={https://github.com/sebmarkbage/ocamlrun-wasm},
|
||||
year={2017}
|
||||
}
|
||||
|
||||
@software{Web17a,
|
||||
title={{Exception Handling Proposal for WebAssembly}},
|
||||
author={{WebAssembly Community Group participants}},
|
||||
url={https://github.com/WebAssembly/exception-handling},
|
||||
year={2017}
|
||||
}
|
||||
|
||||
@software{Web17b,
|
||||
title={{GC Proposal for WebAssembly}},
|
||||
author={{WebAssembly Community Group participants}},
|
||||
url={https://github.com/WebAssembly/gc},
|
||||
year={2017}
|
||||
}
|
||||
|
||||
@software{Web17c,
|
||||
title={{Tail Call Proposal for WebAssembly}},
|
||||
author={{WebAssembly Community Group participants}},
|
||||
url={https://github.com/WebAssembly/tail-call},
|
||||
year={2017}
|
||||
}
|
||||
|
||||
@misc{Mus18,
|
||||
title={{WebAssembly architecture for Go}},
|
||||
author={Musiol, Richard},
|
||||
year={2018},
|
||||
howpublished = "\url{https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0_Nv3OUwjEY5qVCxCup4}"
|
||||
}
|
||||
|
||||
@software{Web18,
|
||||
title={{Reference Types Proposal for WebAssembly}},
|
||||
author={{WebAssembly Community Group participants}},
|
||||
url={https://github.com/WebAssembly/reference-types},
|
||||
year={2018}
|
||||
}
|
||||
|
||||
@software{Web20,
|
||||
title={{Typed Function References Proposal for WebAssembly}},
|
||||
author={{WebAssembly Community Group participants}},
|
||||
url={https://github.com/WebAssembly/function-references},
|
||||
year={2020}
|
||||
}
|
||||
|
||||
@software{Sto21,
|
||||
title={{WASICaml}},
|
||||
author={Stolpmann, Gerd},
|
||||
url={https://github.com/remixlabs/wasicaml},
|
||||
year={2021}
|
||||
}
|
||||
|
||||
@software{Web21a,
|
||||
title={{JavaScript-Promise Integration Proposal for WebAssembly}},
|
||||
author={{WebAssembly Community Group participants}},
|
||||
url={https://github.com/WebAssembly/js-promise-integration},
|
||||
year={2021}
|
||||
}
|
||||
|
||||
@software{Web21b,
|
||||
title={{Stack Switching Proposal for WebAssembly}},
|
||||
author={{WebAssembly Community Group participants}},
|
||||
url={https://github.com/WebAssembly/stack-switching},
|
||||
year={2021}
|
||||
}
|
||||
|
||||
@software{AC22,
|
||||
title={{Wasocaml}},
|
||||
author={Andrès, Léo and Chambart, Pierre},
|
||||
url={https://github.com/ocaml-wasm/wasocaml},
|
||||
year={2022}
|
||||
}
|
||||
|
||||
@software{Mon22,
|
||||
title={{Melange}},
|
||||
author={Monteiro, Antonio Nuno},
|
||||
url={https://github.com/melange-re/melange},
|
||||
year={2022}
|
||||
}
|
||||
|
||||
@misc{Sha22,
|
||||
title={{WebAssembly backend merged into GHC}},
|
||||
author={Shao, Cheng},
|
||||
year={2022},
|
||||
howpublished = "\url{https://www.tweag.io/blog/2022-11-22-wasm-backend-merged-in-ghc}"
|
||||
}
|
||||
|
||||
@software{The22,
|
||||
title={{dart2wasm}},
|
||||
author={{The Dart Project Authors}},
|
||||
year={2022},
|
||||
url={https://github.com/dart-lang/sdk/tree/main/pkg/dart2wasm}
|
||||
}
|
||||
|
||||
@software{Web22,
|
||||
title={{Reference-Typed Strings Proposal for WebAssembly}},
|
||||
author={{WebAssembly Community Group participants}},
|
||||
url={https://github.com/WebAssembly/stringref},
|
||||
year={2022}
|
||||
}
|
||||
|
||||
@misc{AC23,
|
||||
title={{OCaml on WasmGC}},
|
||||
author={Andrès, Léo and Chambart, Pierre},
|
||||
year={2023},
|
||||
howpublished = "\url{https://github.com/WebAssembly/meetings/blob/main/gc/2023/GC-01-10.md}"
|
||||
}
|
||||
|
||||
@software{Vou23,
|
||||
title={{Wasm\_of\_ocaml}},
|
||||
author={Vouillon, Jérôme},
|
||||
url={https://github.com/ocaml-wasm/wasm_of_ocaml},
|
||||
year={2023}
|
||||
}
|
||||
|
||||
@misc{Win23a,
|
||||
title={{a world to win: webassembly for the rest of us}},
|
||||
author={Wingo, Andy},
|
||||
year={2023},
|
||||
howpublished = "\url{https://www.wingolog.org/archives/2023/03/20/a-world-to-win-webassembly-for-the-rest-of-us}"
|
||||
}
|
||||
|
||||
@misc{Win23b,
|
||||
title={{Compiling Scheme to WasmGC}},
|
||||
author={Wingo, Andy},
|
||||
year={2023},
|
||||
howpublished = "\url{https://github.com/WebAssembly/meetings/blob/main/gc/2023/GC-04-18.md}"
|
||||
}
|
||||
|
||||
@software{Win23c,
|
||||
title={{Hoot}},
|
||||
author={Wingo, Andy},
|
||||
url={https://gitlab.com/spritely/guile-hoot/-/blob/main/design/ABI.md},
|
||||
year={2023}
|
||||
}
|
||||
67
wasocaml.tex
67
wasocaml.tex
@ -55,12 +55,22 @@
|
||||
|
||||
\begin{abstract}
|
||||
In this presentation, we explore the compilation of OCaml to WebAssembly (Wasm).
|
||||
The limitations of JavaScript as the default language of the web led to the development of Wasm, a secure and predictable-performance modular language.
|
||||
However, compiling garbage-collected languages to Wasm presents challenges, including the need to compile or re-implement the runtime.
|
||||
Some Wasm extensions are developed by the Wasm working groups to facilitate the compilation of garbage-collected languages.
|
||||
The limitations of JavaScript as the default language of the web led to the
|
||||
development of Wasm, a secure and predictable-performance modular language.
|
||||
However, compiling garbage-collected languages to Wasm presents challenges,
|
||||
including the need to compile or re-implement the runtime.
|
||||
Some Wasm extensions such as Wasm-GC are developed by the Wasm working groups to facilitate
|
||||
the compilation of garbage-collected languages.
|
||||
We present Wasocaml, an OCaml to Wasm-GC compiler.
|
||||
Different strategies to map the OCaml value representation technique to WasmGC and our compilation scheme are detailed.
|
||||
Finally, we describe how we plan to handle the C/JavaScript FFIs and effects handlers within Wasocaml.
|
||||
It is the first compiler for a real-world functional programming language targeting Wasm-GC.
|
||||
Wasocaml confirms the adequacy of the Wasm-GC proposal for a functional language and
|
||||
had an impact on the design of the proposal.
|
||||
Moreover, the compilation strategies developed within Wasocaml are applicable to other
|
||||
compilers and languages.
|
||||
Indeed, two compilers already used a design similar to our.
|
||||
Finally, we describe how we plan to handle the C/JavaScript FFIs and effects
|
||||
handlers, in order to allow developers to easily deploy programs mixing C,
|
||||
JavaScript and OCaml code to the web, while maintaining good performances.
|
||||
\end{abstract}
|
||||
|
||||
% TODO:
|
||||
@ -485,7 +495,7 @@ instead (as it was originally proposed for OCaml 5).
|
||||
|
||||
\paragraph{JavaScript.}
|
||||
|
||||
To re-use existing bindings of OCaml to JavaScript code, we need one more extension: the reference-typed strings proposal~\cite{Web22}. Almost all external calls in the OCaml JavaScript FFI goes through the
|
||||
To re-use existing bindings of OCaml to JavaScript code, we need one more extension: the reference-typed strings proposal~\cite{Web22}. Almost all external calls in the JavaScript FFI goes through the
|
||||
\mintinline{ocaml}{Js.Unsafe.meth_call} function
|
||||
(of type \mintinline{ocaml}{'a -> string -> any array -> 'b})
|
||||
which can be exposed to the Wasm module by the embedder as a function of type:
|
||||
@ -590,12 +600,27 @@ It might be a temporary solution.
|
||||
\subsubsection{Targeting Wasm1}
|
||||
|
||||
\paragraph{Go.}
|
||||
Go compiles to Wasm1~\cite{Mus18}.
|
||||
In order to be able to re-use the Go GC, it must be able to inspect the stack.
|
||||
This is not possible within Wasm.
|
||||
Thus it has to maintain the stack by itself using the memory,
|
||||
which is much slower than using the Wasm stack.
|
||||
% TODO: talk about coroutines ?
|
||||
% TODO: talk about tinygo ?
|
||||
|
||||
\paragraph{Haskell.} ~\cite{Sha22}
|
||||
\paragraph{Haskell.}
|
||||
Haskell also compiles to Wasm~\cite{Sha22}.
|
||||
It has constraints similar to Go and uses similar solutions.
|
||||
In particular, it also uses the memory to manage the stack.
|
||||
% TODO: explain that they had two backends and that Asterius was deprecated ?
|
||||
|
||||
\subsubsection{Targeting Wasm-GC}
|
||||
|
||||
\paragraph{Dart.} ~\cite{The22}
|
||||
\paragraph{Dart.}
|
||||
Dart~\cite{The22} compiles to Wasm-GC.
|
||||
It does not uses \mintinline{wast}{i31ref} and boxes scalars in
|
||||
a \mintinline{wast}{struct}.
|
||||
% TODO: maybe explain this better... (it's not clear how integers are represented natively)
|
||||
|
||||
\paragraph{Scheme.}
|
||||
|
||||
@ -637,18 +662,28 @@ uses of source features at the cost of some small semantical differences.
|
||||
|
||||
\subsubsection{Targeting Wasm}
|
||||
|
||||
\paragraph{Emscripten.}
|
||||
|
||||
%% TODO Cite Emscipten
|
||||
\paragraph{OCamlrun WebAssembly.}
|
||||
OCamlrun WebAssembly~\cite{Mar17} compiles
|
||||
the OCaml runtime and interpreter to Wasm. They are both written in C so it
|
||||
is possible without any Wasm extension.
|
||||
In some cases, it allows to start executing code faster than when compilin
|
||||
OCaml to Wasm.
|
||||
This is because there is less WebAssembly code to compile for the embedder.
|
||||
On the other hand, the execution is slower as it is interpreting OCaml
|
||||
bytecode inside Wasm instead of running a compiled version.
|
||||
|
||||
\paragraph{WASICaml.}
|
||||
WASICaml~\cite{Sto21} is quite similar to OCamlrun WebAssembly.
|
||||
The main difference being that WASICaml does not interpret the bytecode directly
|
||||
but translates it partially to Wasm.
|
||||
It leads to a faster execution.
|
||||
|
||||
%% TODO Cite Wasicaml
|
||||
%% Y a t'il mieux que https://github.com/remixlabs/wasicaml
|
||||
\paragraph{Wasm\_of\_ocaml.}
|
||||
|
||||
%TODO:
|
||||
% Unreleased, fork of jsoo targeting Wasm-GC
|
||||
Wasm\_of\_ocaml~\cite{Vou23} is a fork of Js\_of\_ocaml.
|
||||
It compiles the bytecode to Wasm-GC and re-uses many of the techniques developed by Wasocaml.
|
||||
It does not benefit from the optimisations provided by Flambda.
|
||||
It is also quite restricted in its value representation choice and must use a representation
|
||||
based on arrays.
|
||||
|
||||
\section{Conclusion}
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user