---
# System prepended metadata

title: Phantom WebAssembly proposal

---

# Phantom WebAssembly proposal

## Intro

- To be able to attract the attention of a wide audience of developers, Phantom needs to provide support for at least several mainstream languages. At this moment, Phantom proposes the idea of translation of Java and Python bytecodes to PVM bytecode. It requires the development of translators, VM enhancements, and porting of standard libraries:
    - There is some mismatch in the semantics of Phantom VM and JVM or Python Virtual machine and there are no solutions yet that can compensate it. It has to be done by the enhancement of VM or/and by enhancement of translators, however, there is still a lot of work to do.
    - The other problem is a porting process of standard libraries. Java, for example, has a huge amount of code in the standard library that is implemented via JNI. This code is written in C, C++, and also uses some low-level features of VM accessed via certain API. The amount of work to be done is very large and it also will be difficult to prove that Phantom is compliant with JVM specification.
- Releasing compatibility with JVM or Python VM and Phantom will bring large and active communities, however, it might take too long to implement all required features. Also, Phantom has to be updated with new major releases and features of the selected platform.

- Probably, Phantom needs a more generic solution, that will be able to run specific mainstream languages but will operate on a "lower" level than JVM or Python VM. At this moment we may propose several solutions:
    - Containers
    - Type 2 hypervisor
    - Native compilation
    - WebAssembly

- In this document, we will take a look at the possible approaches of integrating WASM and why it might be beneficial for Phantom

## Why WebAssembly?

1. WASM provides support of multiple mainstream languages like C, C++, Java, Kotlin, Go, C#, TypeScript (and more on [[1]]). Also multiple ports of popular software projects are available. For example Tensorflow, OpenCV, SQLite, QT, Figma (More on [[2]]).
2. In some sense, we may say that the context in which WebAssembly was proposed to work in browsers is close to Phantom. Scripts usually operate with data stored in RAM and don't use files. Phantom provides a single level virtual memory which can be viewed by a program as a large RAM space. Because of that WASM will lead to fewer problems related to differences in ideology.
3. WASM has a simplistic specification. (More info here: [[3]])
    - Its computational model is based on a stack machine
    - It defines only 4 types of values (int32, int64, float32, float64)
    - It provides a simple set of instructions which defines operations on data and control flow
    - Additionally, there are tables, which are arrays that currently allow storing function references and linear memory which is a contiguous, mutable array of raw bytes. 
    - Functions are used as a way to organize the code
    - Also specification defines the way how binaries should be represented (Modules) and the way to integrate the code with the host environment (Embedders)
4. Despite the fact that it comes from a web development environment, the design goals of WASM were to make it fast, secure, and portable [[4]].
5. Unlike Java it doesn't require implementing a standard library, which greatly reduces the amount of work. However, need to implement system interfaces and interaction mechanism between them, what has to be implemented in both cases. WASM proposes WebAssembly System Interface (WASI) for that purpose [[5]].
6. Since the specification is simple, implementations do not contain a lot of code. For example, the WAMR repository [[6]] contains only ~90 kLOC.

## How to integrate WASM into Phantom?

What are the possible ways of integrating WebAssembly into Phantom?

1. Write an implementation of WASM VM in Phantom language. It is a good approach since most of the code will be located in userspace, however, it will take a lot of effort not only related to WASM itself but also related to Phantom language compiler and bytecode VM. Also, there might be issues related to the performance of that solution.
2. Translate WASM to Phantom bytecode. In this case, the performance will be better, however, Phantom VM will require some modifications and it has to be compliant with WASM specification.
3. Integrate an existing WASM runtime as an internal class. There are multiple open-source WASM runtimes available at this moment. It would be a nice idea to select the most suitable implementation and integrate it into the code of VM as an internal class. For userspace programs, the instance of WASM runtime will be available as the object similar to the existing Phantom class loader. However, it should be able to store data and execution state in persistent memory as objects that probably should be accessible to other Phantom programs. As a starting point, WebAssembly Micro Runtime (WAMR) can be used [[6]]. In this case, not many modifications in PVM are needed, since we don't require it to be compatible with WASM.
4. Replace Phantom VM with WASM VM. It is an expensive option that also may affect the concepts of Phantom in general.

## Drawbacks of WASM in Phantom

What are the drawbacks of WASM in Phantom?

- WebAssembly is a relatively new technology. The specification of WASM is stable but not yet complete as well as tools around WASM.
- WASI is also still experimental. It is small and may lack some basic features provided by traditional operating systems.
- Definitely, more problems will arise after a more in-depth analysis of specification and implementations of WASM

## Conclusion

WASM is able to bring support of several mainstream languages to Phantom OS with a relatively small amount of effort since we are able to reuse existing translators/compilers and we don't need to implement a large standard library between userspace and system interfaces. However, more analysis should be performed to develop a solution that will take into account all tradeoffs.

## References

[[1]] - A curated list of languages that compile directly to or have their VMs in WebAssembly (https://github.com/appcypher/awesome-wasm-langs)
[[2]] - List of projects implemented in WebAssembly (https://madewithwebassembly.com/all-projects/)
[[3]] - WASM overview (https://webassembly.github.io/spec/core/intro/overview.html)
[[4]] - WASM introduction (https://webassembly.github.io/spec/core/intro/introduction.html#design-goals)
[[5]] - Standardizing WASI: A system interface to run WebAssembly outside the web (https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface)
[[6]] - WebAsembly Micro Runtime (WAMR) repository (https://github.com/bytecodealliance/wasm-micro-runtime)



[1]: https://github.com/appcypher/awesome-wasm-langs
[2]: https://madewithwebassembly.com/all-projects/
[3]: https://webassembly.github.io/spec/core/intro/overview.html
[4]: https://webassembly.github.io/spec/core/intro/introduction.html#design-goals
[5]: https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface
[6]: https://github.com/bytecodealliance/wasm-micro-runtime
