Compiling Bigloo Scheme to WebAssembly
Compiling Bigloo Scheme to WebAssembly involves building it twice, facing architecture discrepancies, function pointer casting issues, and producing larger binaries, highlighting the complexities of adapting languages to new platforms.
Read original article
the experience highlighted the complexities involved in compiling Bigloo Scheme to WebAssembly (Wasm). The process requires building Bigloo twice: once natively and once to Wasm, ensuring that the runtime libraries are also compiled to Wasm for successful execution. Challenges included discrepancies between 32-bit and 64-bit architectures affecting value tagging, which led to incorrect outputs in compiled programs. Additionally, function pointer casting issues arose due to the strict type system of Wasm, which does not allow undefined behavior common in C. While the initial goal was to create a pipeline for compiling JavaScript to Wasm via Hopc, the resulting binaries were significantly larger than expected, with the smallest successful output being 29MB. The exploration revealed potential optimizations, such as disabling certain features to reduce binary size, but also indicated that further work is needed to make the process practical for real-world applications. Overall, the endeavor provided valuable insights into the intricacies of language compilation and the challenges of adapting existing systems to new environments like Wasm.
- Compiling Bigloo Scheme to WebAssembly involves building the language twice to ensure runtime libraries are included.
- Discrepancies between 32-bit and 64-bit architectures can lead to incorrect outputs in compiled programs.
- Function pointer casting issues in Wasm arise from its strict type system, complicating the compilation process.
- The resulting binaries from the compilation process can be significantly larger than expected, with optimizations needed for practical use.
- The experience highlights the complexities of porting programming languages to new platforms like WebAssembly.
Related
CPS in Hoot
The Hoot Scheme-to-Wasm compiler uses CPS transformation to handle push calls in WebAssembly. Strategies like generic slicing and CPS transformation are explored, enabling features like Fibers and promise integration. Performance impact is under evaluation.
Dynamic Translation of Smalltalk to WebAssembly
The article explores Smalltalk code translation to WebAssembly (WASM) within the Catalyst project. It details levels of Smalltalk, JavaScript, and WASM, focusing on direct Smalltalk to WASM optimization. A new translator, WATCompiledMethodTranslator, aids in this process, exemplified by a Smalltalk expression conversion. Creation of a WASM module for Smalltalk methods is explained, highlighting performance advantages and potential future comparisons with dynamic JS translations. Collaboration in the Smalltalk community is encouraged for further advancement.
Compilation of JavaScript to WASM, Part 2: Ahead-of-Time vs. JIT
Chris Fallin's blog post discusses his AOT compiler for JavaScript to WebAssembly, achieving 3-5x performance improvements while addressing challenges like dynamic typing and Wasm platform constraints.
Compilation of JavaScript to WASM, Part 3: Partial Evaluation
The article concludes a series on compiling JavaScript to WebAssembly, discussing challenges, proposing a portable interpreter for debugging, and introducing the Futamura projection for program compilation and analysis.
WASM Is the New CGI
WebAssembly (Wasm) is transforming web application development by enhancing performance, enabling efficient code execution, and addressing serverless cold start issues, despite limitations like lack of native threading and JIT compilation.
0 commentsRelated
CPS in Hoot
The Hoot Scheme-to-Wasm compiler uses CPS transformation to handle push calls in WebAssembly. Strategies like generic slicing and CPS transformation are explored, enabling features like Fibers and promise integration. Performance impact is under evaluation.
Dynamic Translation of Smalltalk to WebAssembly
The article explores Smalltalk code translation to WebAssembly (WASM) within the Catalyst project. It details levels of Smalltalk, JavaScript, and WASM, focusing on direct Smalltalk to WASM optimization. A new translator, WATCompiledMethodTranslator, aids in this process, exemplified by a Smalltalk expression conversion. Creation of a WASM module for Smalltalk methods is explained, highlighting performance advantages and potential future comparisons with dynamic JS translations. Collaboration in the Smalltalk community is encouraged for further advancement.
Compilation of JavaScript to WASM, Part 2: Ahead-of-Time vs. JIT
Chris Fallin's blog post discusses his AOT compiler for JavaScript to WebAssembly, achieving 3-5x performance improvements while addressing challenges like dynamic typing and Wasm platform constraints.
Compilation of JavaScript to WASM, Part 3: Partial Evaluation
The article concludes a series on compiling JavaScript to WebAssembly, discussing challenges, proposing a portable interpreter for debugging, and introducing the Futamura projection for program compilation and analysis.
WASM Is the New CGI
WebAssembly (Wasm) is transforming web application development by enhancing performance, enabling efficient code execution, and addressing serverless cold start issues, despite limitations like lack of native threading and JIT compilation.