WAMR TSC Meeting - 2023/3/20

# WAMR TSC Meeting - 2023/3/20 Attendees: - Xu, Jun1/Wang, Xin/Huang, Wenyong/He, Liang - Intel - Trenner, Thomas/Ermler, Rene/Woods, Chris - Siemens - Emiel Van Severen - Maricin - Amzaon - Dongsheng Yan - Sony ## Updates 1. The recent feature development progress and release 1.2.0 plan (wenyong) - Multi-tier JIT and running modes control - Tier up from Fast JIT to LLVM JIT - Set running mode for runtime, wasm module instance and iwasm - Upgrade toolkits’ version - llvm-15.0, wasi-sdk-19.0, emsdk-3.1.28, wabt 1.0.31 and so on - GC refactoring for interpreter mode (branch dev/gc_refactor) - wasi-threads support - ts2wasm compiler (branch ts2wasm_experiment) - Fast JIT multi-threading support - Python binding for WAMR APIs (wasm_export.h) 2. Github front page readme update and new blogs: - https://bytecodealliance.github.io/wamr.dev/blog/understand-the-wamr-heap/ - https://bytecodealliance.github.io/wamr.dev/blog/understand-the-wamr-stacks/ - https://bytecodealliance.github.io/wamr.dev/blog/introduction-to-wamr-running-modes/ # Opens 1. Wenyong: in last TSC meeting we mentioned to split the repo and move some components out, how about migrating core/app-mgr and core/app-framework to other repo first? e.g. bytecodealliance/wamr-iot? - good idea. Get a few more name candidates. - Need to move some samples (simple, lvgl) as well 3. checkpoint-restore proposal [link](https://bytecodealliance.zulipchat.com/#narrow/stream/290350-wamr/topic/checkpoint-restore) ## Exception handling status (Chris) - WebAssembly set exceptions don't look like C++ or Java. Exceptions are different, but when you throw an exception, you throw a list of parameters and that's what's specified in the tag. - The current API structure uses exception to mean runtime exception. Some potential of confusion and the naming and how we call things, but for, at least for, for for initial version we wanna focus on making sure we get the bytecode with the exception supported - When you rethrow an exception, you rethrow with a relative marker. So in the specifications and there is a potential that that could be wrong and the same with delegates. So we would mark those as and check that those are valid and if they're not then that would be essentially a bad bad operand to an instruction and we would report it with this string that we returned from runtime get acception - Error information can be passed in a variable list length and type list of arguments ## GPIO/SPI WASI API - https://github.com/WebAssembly/meetings/blob/main/wasi/2023/WASI-03-09.md - Emiel Van Severen: - Make application platform agnostic. Maybe limilar with how Android app uses manifest to fit different devices. - what kind of requirements we want to define in in components? So these are the initial points I went to work on. Create a mail loop for offline discussion. - Idea comes from the embedded world within rust. Different hardware abstraction layers for different underlying underlying architectures. And my idea is basically to have different or to create on the native level different halls which implement these interfaces - Jun Xu: Intel sharing - GPIO API in an internal product - we have some internal product which uses the Zephyr, a Realtime OS. and there is a requirement that the applications running on inside the Wasm runtime need to access the peripherals like GPI, GPI and timers. ## TS2Wasm status (Not talked due time constraint) - SIG-TypeScript-Compilation proposal：https://github.com/bytecodealliance/governance/pull/28 - Open sourced the PoC in the https://github.com/bytecodealliance/wasm-micro-runtime/tree/ts2wasm_experiment - Tehncial intro (if time permits)