jserv commented 1 year ago

iamlouk/riscv64-sim is written in C and capable of being translated into WebAssembly. Check its web demo. Some web-based (open source) RISC-V simulations:

WebRISC-V: 5-stage Graphical Pipeline 32/64-bit Simulator
emulsiV

The goal of this task is to expand rv32emu to the simulator, which will be used to teach computer architecture fundamentals, based on the existing RISC-V codebase. Incomplete attempt: rv32emu-wasm

jserv commented 1 year ago

We might need RISC-V instruction decoder for web-based execution. See rvcodec.js: an online encoder/decoder for RISC-V instructions

jserv commented 1 year ago

Recent rv32emu relies on tail-call optimization (TCO), which causes build problems with Emscripten. Thus, we have to turn it off. Apply the following changes:

diff --git a/src/common.h b/src/common.h
index 62b66bd..374bcf3 100644
--- a/src/common.h
+++ b/src/common.h
@@ -43,7 +43,7 @@
  * around this, the compiler attribute 'musttail' is used, which forces TCO
  * even without optimizations enabled.
  */
-#if defined(__has_attribute) && __has_attribute(musttail)
+#if defined(__has_attribute) && __has_attribute(musttail) && !defined(__wasm__)
 #define MUST_TAIL __attribute__((musttail))
 #else
 #define MUST_TAIL
diff --git a/src/io.c b/src/io.c
index 5d7a37d..f3de262 100644
--- a/src/io.c
+++ b/src/io.c
@@ -17,8 +17,8 @@
 #include "io.h"

 static uint8_t *data_memory_base;
-/* set memory size to 2^32 bytes */
-#define MEM_SIZE 0x100000000ULL
+/* set memory size to 2^31 bytes */
+#define MEM_SIZE 0x10000000ULL

 memory_t *memory_new()
 {

Then, build this project via emcc:

make CC=emcc ENABLE_SDL=0 ENABLE_GDBSTUB=0

build/rv32emu.wasm should be generated.

See Tail Call Extension

ChinYikMing commented 9 months ago

I am going to study and solve this issue. May I know if the original assignee still working on it?

jserv commented 9 months ago

I am going to study and solve this issue. May I know if the original assignee still working on it?

Go ahead!

ChinYikMing commented 9 months ago

Tail call optimization(TCO) is supported by Chrome (version 112) natively, see roadmap of webassembly. If tail call optimization is enabled during the build, only Chrome can run the wasm. So, Chrome will be the main experimental runtime environment to adapt TCO for now.

jserv commented 9 months ago

Tail call optimization is supported by Chrome (version 112) natively, see roadmap of webassembly. Thus, if tail call optimization is enabled during the build, only Chrome can run the wasm.

It is reasonably acceptable to restrict the WebAssembly runtime environments, given that the WebAssembly-built rv32emu is highly experimental.

jserv commented 9 months ago

After the initial WebAssembly build (#293), we can proceed with the following action items:

Create an HTML page, which we could potentially host on GitHub Pages, to enable the WebAssembly-built rv32emu to run sample RISC-V ELF files. We will also need a web-based console for stdout.
Ensure that RV32-built video games such as Doom and Quake can run on the Chrome web browser in the form of WebAssembly.
(Optional) Implement single-stepping execution, along with web-based register and internal state displays, similar to what Riples provides. This would be a valuable addition.

ChinYikMing commented 9 months ago

Suppress the warning that generated when exporting functions from the same translation unit of the main function (e.g., print_usage) but the main function is not exported, see issue(fixed)

ChinYikMing commented 8 months ago

Create an HTML page, which we could potentially host on GitHub Pages, to enable the WebAssembly-built rv32emu to run sample RISC-V ELF files. We will also need a web-based console for stdout.

This wasm branch has attempted to support this. Try it out by following the README.

It requires some source code modifications to work:

Remove static modifier from MEMIO in src/main.c. So that, the translation unit of main.c (main.o) can export the functions.
Allocate required memory size using pass by value because WebAssembly's page size is 64KiB thus default memory size MEM_SIZE(2^32 - 1) can not be applied. In order to fix this, I propose that declare a mem_size parameter in state_new function and this parameter is passed to memory_new function in further. Note that rv32emu can still using MEM_SIZE outside the web.

The following are the main changes:

[ ] src/main.c


--- a/src/main.c
+++ b/src/main.c
@@ -44,7 +44,7 @@ static bool opt_misaligned = false;

#define MEMIO(op) on_mem_##op
#define IO_HANDLER_IMPL(type, op, RW)                                     \

static IIF(RW)( \
IIF(RW)( \ / W / void MEMIO(op)(riscv_wordt addr, riscv##type##t data), \ / R / riscv##type##_t MEMIO(op)(riscv_word_t addr)) \ { \ @@ -222,7 +222,7 @@ int main(int argc, char **args) .allow_misalign = opt_misaligned, };
state_t *state = state_new();
state_t *state = state_new(MEM_SIZE);

/ find the start of the heap / const struct Elf32_Sym *end;

[ ] src/riscv.h

--- a/src/riscv.h
+++ b/src/riscv.h
@@ -222,7 +222,7 @@ typedef struct {
} state_t;

/* create a state */
-state_t *state_new(void);
+state_t *state_new(uint32_t mem_size);

/* delete a state */
void state_delete(state_t *s);

[ ] src/riscv.c


--- a/src/riscv.c
+++ b/src/riscv.c
@@ -294,11 +294,11 @@ void rv_reset(riscv_t *rv, riscv_word_t pc, int argc, char **args)
 rv->halt = false;
}

-state_t state_new(void) +state_t state_new(uint32_t mem_size) { state_t *s = malloc(sizeof(state_t)); assert(s);

s->mem = memory_new();
s->mem = memory_new(mem_size); s->break_addr = 0;

s->fd_map = map_init(int, FILE *, map_cmp_int);

[ ] src/io.h


--- a/src/io.h
+++ b/src/io.h
@@ -8,16 +8,23 @@
#include <stdint.h>
#include <string.h>

-/* Directly map a memory with a size of 2^32 bytes. All memory read/write

- operations can access this memory through the memory subsystem. +/*
- set memory size to 2^32 - 1 bytes
*
- The memory size is set to 2^32 - 1 bytes in order to make this emulator
- portable for both 32-bit and 64-bit platforms. As a result, it can access
- any segment of the memory on either platform. Furthermore, it is safe
- because most of the test cases' data memory usage will not exceed this
- memory size. */ +#define MEM_SIZE 0xFFFFFFFFULL
typedef struct { uint8_t *mem_base; uint64_t mem_size; } memory_t;

-memory_t memory_new(void); +memory_t memory_new(uint32_t mem_size); void memory_delete(memory_t *m);

/ read a C-style string from memory /


- [ ] `src/io.c`
```diff
--- a/src/io.c
+++ b/src/io.c
@@ -17,44 +17,33 @@

 static uint8_t *data_memory_base;

-/*
- * set memory size to 2^32 - 1 bytes
- *
- * The memory size is set to 2^32 - 1 bytes in order to make this emulator
- * portable for both 32-bit and 64-bit platforms. As a result, it can access
- * any segment of the memory on either platform. Furthermore, it is safe
- * because most of the test cases' data memory usage will not exceed this
- * memory size.
- */
-#define MEM_SIZE 0xFFFFFFFFULL
-
-memory_t *memory_new(void)
+memory_t *memory_new(uint32_t mem_size)
 {
     memory_t *mem = malloc(sizeof(memory_t));
     assert(mem);
 #if HAVE_MMAP
-    data_memory_base = mmap(NULL, MEM_SIZE, PROT_READ | PROT_WRITE,
+    data_memory_base = mmap(NULL, mem_size, PROT_READ | PROT_WRITE,
                             MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
     if (data_memory_base == MAP_FAILED) {
         free(mem);
         return NULL;
     }
 #else
-    data_memory_base = malloc(MEM_SIZE);
+    data_memory_base = malloc(mem_size);
     if (!data_memory_base) {
         free(mem);
         return NULL;

ChinYikMing commented 8 months ago

Is it feasible for me to host the relevant porting files (such as HTML, JS files, etc.) and then rv32emu submodule for them? So that, rv32emu can adapt to different porting implementation.

I am not sure if an HTML submodule may be hosted on a github page.

jserv commented 8 months ago

Is it feasible for me to host the relevant porting files (such as HTML, JS files, etc.) and then rv32emu submodule for them? So that, rv32emu can adapt to different porting implementation.

I think so. Take Ripes for example. There are two directories resources and appdir preserving resources files.

I am not sure if an HTML submodule may be hosted on a github page.

We can follow the approach of rv32emu-bench.

jserv commented 8 months ago

This wasm branch has attempted to support this. Try it out by following the README. It requires some source code modifications to work:

Remove static modifier from MEMIO in src/main.c. So that, the translation unit of main.c (main.o) can export the functions.

Reflecting on the feedback from the wasm branch, it seems appropriate to refine the APIs in the src/riscv.h header. The focus should be on achieving a higher level of abstraction by integrating detailed components like memory, state, and I/O into a more unified API structure. For inspiration on creating a clean and elegant C API for executing RISC-V programs, consider examining the approach used by libriscv.

Last year, when developing semu, I improved the APIs to make them cleaner. The riscv.h header was designed to abstract the virtual machine's internals, avoiding explicit cross-references among several implementation-focused headers. Now, I believe it is time to apply a similar approach to the rv32emu project. Without this evolution, rv32emu continually faces challenges in adapting to various runtime environments.

If you are in agreement with the statement I've made, let's proceed by gradually refining our existing public headers. The aim is to enhance encapsulation while ensuring there are no disruptions to functionality.

ChinYikMing commented 8 months ago

Is it feasible for me to host the relevant porting files (such as HTML, JS files, etc.) and then rv32emu submodule for them? So that, rv32emu can adapt to different porting implementation.

I think so. Take Ripes for example. There are two directories resources and appdir preserving resources files.

I am not sure if an HTML submodule may be hosted on a github page.

We can follow the approach of rv32emu-bench.

To sum up, the Github page deployment will be a repository with two submodules: "wasm and corresponding glue js"(generated by emcc and hosted in sysprog21 organization) and "wasm porting implemention"(hosted in my personal repository). Some CI might be needed to automate the build and store actions.

ChinYikMing commented 8 months ago

Reflecting on the feedback from the wasm branch, it seems appropriate to refine the APIs in the src/riscv.h header. The focus should be on achieving a higher level of abstraction by integrating detailed components like memory, state, and I/O into a more unified API structure. For inspiration on creating a clean and elegant C API for executing RISC-V programs, consider examining the approach used by libriscv.

Last year, when developing semu, I improved the APIs to make them cleaner. The riscv.h header was designed to abstract the virtual machine's internals, avoiding explicit cross-references among several implementation-focused headers. Now, I believe it is time to apply a similar approach to the rv32emu project. Without this evolution, rv32emu continually faces challenges in adapting to various runtime environments.

If you are in agreement with the statement I've made, let's proceed by gradually refining our existing public headers. The aim is to enhance encapsulation while ensuring there are no disruptions to functionality.

I agree with that the the RISC-V APIs should have higher level of abstraction. Consequently, they could be easily ported to multiple platforms (e.g., desktop) or maintained. I will try to investigate the abstraction of APIs from libriscv and semu for further discussion.

jserv commented 8 months ago

To sum up, the Github page deployment will be a repository with two submodules: "wasm and corresponding glue js"(generated by emcc and hosted in sysprog21 organization) and "wasm porting implemention"(hosted in my personal repository). Some CI might be needed to automate the build and store actions.

Consider awtk as another example - it is a window widget set written in C that also supports a web-based runtime through awtk-web. In the future, with the integration of semu's developments into rv32emu, we should be capable of hosting an online emulator akin to RVVM.

jserv commented 8 months ago

This wasm branch has attempted to support this. Try it out by following the README.

Test environment: macOS 14.2.1 + Apple Silicon (M1)

I have installed emcc via Homebrew.

$ emcc --version | head -1
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.50-git

After executing make CC=emcc ENABLE_SDL=0 ENABLE_GDBSTUB=0, I got the following messages:

wasm-ld: error: unknown argument: -no_warn_duplicate_libraries

The issue was caused by my error in toolchain configuration detection, and I will fix it later.

After quick fix, both Drystone and CoreMark run inside Chrome browser. Current rv32emu/wasm performance:

Dhrystone: 82 DMIPS
CoreMark: 134 iter/s

RVVM:

CoreMark: 366 iter/s

ChinYikMing commented 8 months ago

Test environment: macOS 14.2.1 + Apple Silicon (M1) [...] both Drystone and CoreMark run inside Chrome browser. Current rv32emu/wasm performance:

Dhrystone: 82 DMIPS

CoreMark: 134 iter/s RVVM:

CoreMark: 366 iter/s

WebAssembly performance might be tuned after the basic simulation(e.g., sample ELF and Doom & Quake video game) are done.

ChinYikMing commented 8 months ago

In order to satisfy the browser's event model, the wasm branch supported cooperative multitasking mode. Try it out at demo here(only runable in Chrome). Run "ieee754.elf" to observe a notable change. The line prints out while the program is executing rather than flushing the entire buffer once the run is complete(in other words, update DOM as soon as possible). This can increase the interaction between the user and program.

This change requires some modification of source code since it leverages the APIs of Emscripten (e.g., __EMSCRIPTEN__ predefined macro, emscripten_set_main_loop_arg, emscripten_cancel_main_loop, see commit). Is it possible for them to be added to the main branch afterwards? Actually, I am still trying to figure out how to keep the source code unchanged.

ChinYikMing commented 8 months ago

Ensure that RV32-built video games such as Doom and Quake can run on the Chrome web browser in the form of WebAssembly.

Shooting games like Doom and Quake may now be rendered on a web browser, however the frame rate is low(see demo). I will investigate more after sound system is set up successfully because the failure of initialization of sound system will make rv32emu exit early. see issue.

ChinYikMing commented 8 months ago

Tail call optimization(TCO) is supported by Chrome (version 112) natively, see roadmap of webassembly. If tail call optimization is enabled during the build, only Chrome can run the wasm. So, Chrome will be the main experimental runtime environment to adapt TCO for now.

Firefox version 121 supports TCO, so both Chrome and Firefox can be the experimental runtime environment now.

ChinYikMing commented 8 months ago

Ensure that RV32-built video games such as Doom and Quake can run on the Chrome web browser in the form of WebAssembly.

Shooting games like Doom and Quake may now be rendered on a web browser, however the frame rate is low(see demo). I will investigate more after sound system is set up successfully because the failure of initialization of sound system will make rv32emu exit early. see issue.

As I tweaking the cycle_per_step to 2000000, Doom and Quake run more smoothly than before. Sound system is set up successfully by linking the ported SDL library correctly. The sound are played by Timidity and the sound effect is decent in Quake but not very nice(especially on pistol sound effect) in Doom (maybe will try FluidSynth).

A small changes have to be applied to sound system calls(in "src/syscall_sdl.c"):

static void play_sfx(riscv_t *rv)
{
    ...
    pthread_create(&sfx_thread, NULL, sfx_handler, &sfx);
+#ifdef __EMSCRIPTEN__
+   pthread_join(sfx_thread, NULL);
+#endif
}

static void play_music(riscv_t *rv)
{
    ...
    pthread_create(&music_thread, NULL, music_handler, &music);
+#ifdef __EMSCRIPTEN__
+   pthread_join(music_thread, NULL);
+#endif
}

I found that emcc compiled web workers are not reused, so adding pthread_join makes them reusable. Otherwise, will get error: Tried to spawn a new thread, but the thread pool is exhausted. After applying this patch, the browser would suggest that blocking main thread(calling pthread_join) is dangerous, but it is safe actually since the sfx_handler and music_handler do not contain any blocking call.

Demo:

Note that due to the large size of the WASM file, the loading may take some time. I might rewrite the UI for noticing that the loading process (maybe a loading bar indicator). Also, please click the canvas to trigger the Web Audio API.

Next, I will focus on design, discuss and refactor riscv.[ch] and io.[ch] API for easier porting to different runtime.

ChinYikMing commented 8 months ago

we could potentially host on GitHub Pages

Multithreading in Emscripten requires SharedArrayBuffer. To allow the browser to support "SharedArrayBuffer", we have to add custom response headers: "Cross-Origin-Opener-Policy" and "Cross-Origin-Embedder-Policy", see security requirements. Moreover, it is necessary for the server to have an active SSL certificate for the browser to enable "SharedArrayBuffer".

Due to the limitation for the customization of github pages response headers (maybe fixed by this blog but seems cumbersome), github pages is not a suitable place to serve multithreading applications like Quake and Doom but suitable for those sample ELF executable which does not require multithreading. Thus, I believe a better way is that having a dedicated server with an active SSL certificate and the ability to set custom response headers to serve both multithreading and non-multithreading WebAssembly applications.

ChinYikMing commented 8 months ago

rv32emu public APIs might be refactored over the time, writing all exported rv32emu public APIs in Makefile(see EXPORTED_FUNCTIONS in Makefile) is not an ideal choice since keep updating Makefile to adapt new rv32emu public API is weird. Instead, we can create a file to store all exported rv32emu public APIs and make emcc link to it during compile time. It is sufficient to edit the file in order to create a new rv32emu public API. See configs of awtk-web.

jserv commented 8 months ago

Ben Smith's remarkable experiment, which involves compiling and running Clang in a web browser, is detailed in his project Clang/LLD in WebAssembly. Drawing inspiration from this, we have the potential to develop WebAssembly-based versions of Clang/LLD specifically for RISC-V, along with an in-memory filesystem. This method would enable the versatile usage of these tools in a web environment. It would facilitate not only the compilation and execution of C source files but also their operation on a WebAssembly-built rv32emu.

check the file riscv-gnu-toolchain/Makefile.in and look for the target named build-llvm-newlib.

ChinYikMing commented 6 months ago

Demo:

Doom

Quake

Falling-nes

Use the latest riscv.[ch] public APIs to port rv32emu to WebAssembly and run Falling-nes for testing (performance can still be improved but it works!). See branch.

ChinYikMing commented 6 months ago

293 enable LTO to default WebAssembly build using emcc, but it fails on building emscripten-port SDL2. To be more precise, the rv32emu WebAssembly build will fail if `ENABLE_SDL=1` is configured. As a result , I think we can enable LTO for CLI programs but disable it for programs that utilize SDL-related functions. (Hopefully emscripten will fix it)

Demo:

Doom

Quake

Falling-nes

I aware this problem, so above demo programs are build with configuration ENABLE_LTO=0.

ChinYikMing commented 6 months ago

I think it is time to merge some results to upstream. The plan is as follows:

Enable to build rv32emu to wasm and run CLI programs using node
Enable to build rv32emu to wasm and run CLI and SDL programs and start local web server to serve them using script
Deploy the wasm to dedicated server

jserv commented 6 months ago

293 enable LTO to default WebAssembly build using emcc, but it fails on building emscripten-port SDL2. To be more precise, the rv32emu WebAssembly build will fail if ENABLE_SDL=1 is configured. As a result , I think we can enable LTO for CLI programs but disable it for programs that utilize SDL-related functions. (Hopefully emscripten will fix it)

Disabling LTO for WebAssembly-based builds is acceptable since, thus far, the optimizations have not shown significant impact.

jserv commented 6 months ago

I think it is time to merge some results to upstream. The plan is as follows:

Enable to build rv32emu to wasm and run CLI programs using node

Are there alternative methods to execute WebAssembly programs using languages like C, PHP, or Python, rather than relying on Node.js?

ChinYikMing commented 6 months ago

I think it is time to merge some results to upstream. The plan is as follows:

Enable to build rv32emu to wasm and run CLI programs using node

Are there alternative methods to execute WebAssembly programs using languages like C, PHP, or Python, rather than relying on Node.js?

So far as I know, there are two main ways to execute WebAssembly programs, one is JavaScript interpreter (NodeJS or Browser JS engine), second is wasm interpreter (e.g., wasmtime).

I think you want the least dependency for deployment?

jserv commented 6 months ago

So far as I know, there are two main ways to execute WebAssembly programs, one is JavaScript interpreter (NodeJS or Browser JS engine), second is wasm interpreter (e.g., wasmtime). I think you want the least dependency for deployment?

Identifying web browsers like Chrome as necessary for running Emscripten-generated programs is practical. My aim is to establish a straightforward setup for those interested in exploring WebAssembly translation within common macOS or GNU/Linux environments.

ChinYikMing commented 6 months ago

Identifying web browsers like Chrome as necessary for running Emscripten-generated programs is practical. My aim is to establish a straightforward setup for those interested in exploring WebAssembly translation within common macOS or GNU/Linux environments.

Unfortunately, Safari has not yet support TCO (see roadmap of WebAssembly), otherwise macOS users can depend it as default runtime. However, we could target Debian's GNOME users since the default web browser is Firefox and it supports TCO since version 121. Thus, requiring users who outside Debian's GNOME to install Chrome or Firefox as dependency to run wasm CLI and video games is necessary.

I am wondering to consider NodeJS as dependency since the users can run wasm CLI without the need of web browsers.

jserv commented 6 months ago

I am wondering to consider NodeJS as dependency since the users can run wasm CLI without the need of web browsers.

Also, consider checking out WasmEdge. The developers behind this project are friendly towards us — they are Taiwanese developers keen on exploring more use cases.

ChinYikMing commented 6 months ago

I am wondering to consider NodeJS as dependency since the users can run wasm CLI without the need of web browsers.

Also, consider checking out WasmEdge. The developers behind this project are friendly towards us — they are Taiwanese developers keen on exploring more use cases.

I gave it a try and faced some problems:

[2024-03-12 10:47:26.703] [error] instantiation failed: unknown import, Code: 0x62
[2024-03-12 10:47:26.703] [error]     When linking module: "env" , function name: "_emscripten_fs_load_embedded_files"
[2024-03-12 10:47:26.703] [error]     At AST node: import description
[2024-03-12 10:47:26.703] [error]     This may be the import of host environment like JavaScript or Golang. Please check that you've registered the necessary host modules from the host programming language.
[2024-03-12 10:47:26.703] [error]     At AST node: import section
[2024-03-12 10:47:26.703] [error]     At AST node: module

Similar issue faced by somebody else. Based on the discussion, I think WasmEdge is not compatible to all emcc-generated wasm now. I will try to check some docs and figure out how to make emcc and WasmEdge compatible(maybe tune some compiler options in emcc).

jserv commented 6 months ago

However, we could target Debian's GNOME users since the default web browser is Firefox and it supports TCO since version 121. Thus, requiring users who outside Debian's GNOME to install Chrome or Firefox as dependency to run wasm CLI and video games is necessary.

How about bundling Electron? I have no idea about web-based technologies yet. What I expect is an easy setup for launching the built WebAssembly programs.

ChinYikMing commented 6 months ago

However, we could target Debian's GNOME users since the default web browser is Firefox and it supports TCO since version 121. Thus, requiring users who outside Debian's GNOME to install Chrome or Firefox as dependency to run wasm CLI and video games is necessary.

How about bundling Electron? I have no idea about web-based technologies yet. What I expect is an easy setup for launching the built WebAssembly programs.

Electron is a combination of Chromium + Node.js. In other words, Electron depends on Node.js. If we want to use Electron, we actually just need to use Node.js.

For reference, here is the list of available wasm runtime. A similar issue is discussed in Hacker News.

ChinYikMing commented 6 months ago

Multithreading in Emscripten requires SharedArrayBuffer. To allow the browser to support "SharedArrayBuffer", we have to add custom response headers: "Cross-Origin-Opener-Policy" and "Cross-Origin-Embedder-Policy", see security requirements. Moreover, it is necessary for the server to have an active SSL certificate for the browser to enable "SharedArrayBuffer".

Could you verify that the response headers of the dedicated server include these two? I found that they are not response from the server.

ChinYikMing commented 6 months ago

I tried to use emcc version 3.1.55 for porting and the video game sound effects are working but background musics do not. After some debugging, I found that the latest emcc will fetch the latest SDL2_mixer library for porting. After switching version back to 3.1.51 (the previous demonstration using this emcc version), both are working.

As a result, I would like to lock emcc version to 3.1.51 until we figure out what the root cause is.

Perhaps we can report the issue to Emscripten or SDL.

ChinYikMing commented 6 months ago

we could potentially host on GitHub Pages

Multithreading in Emscripten requires SharedArrayBuffer. To allow the browser to support "SharedArrayBuffer", we have to add custom response headers: "Cross-Origin-Opener-Policy" and "Cross-Origin-Embedder-Policy", see security requirements. Moreover, it is necessary for the server to have an active SSL certificate for the browser to enable "SharedArrayBuffer".

Due to the limitation for the customization of github pages response headers (maybe fixed by this blog but seems cumbersome), github pages is not a suitable place to serve multithreading applications like Quake and Doom but suitable for those sample ELF executable which does not require multithreading. Thus, I believe a better way is that having a dedicated server with an active SSL certificate and the ability to set custom response headers to serve both multithreading and non-multithreading WebAssembly applications.

The coi-serviceworker comes to help. We can embed it to our index.html when hosting on GitHub Pages. Try it out at here.

ChinYikMing commented 5 months ago

Dhrystone: 82 DMIPS

CoreMark: 134 iter/s

RVVM:

CoreMark: 366 iter/s

Running on GitHub Pages:

Dhrystone: 589 DMIPS
CoreMark: 402 iter/s

The only changes thing is the CYCLE_PER_STEP (from 100 to 2000000). It would and might be clearer after analyzing the cooperative runtime between browser and wasm.

jserv commented 5 months ago

JIT compilers which can generate WebAssembly:

v86
wcc

ChinYikMing commented 5 months ago

Since #385 is merged, we can move forward to deploy wasm application on GitHub Pages.

Shall we host on rv32emu upstream's master or other branch? I am prefer other branch since the root directory of GitHub Pages are limited to "/docs" or "/" and we might not want to mess master branch.

jserv commented 5 months ago

Shall we host on rv32emu upstream's master or other branch? I am prefer other branch since the root directory of GitHub Pages are limited to "/docs" or "/" and we might not want to mess master branch.

I created a repository, rv32emu-demo, and specify @ChinYikMing as the administrator. Please follow the way how rv32emu-bench works.

ChinYikMing commented 5 months ago

Shall we host on rv32emu upstream's master or other branch? I am prefer other branch since the root directory of GitHub Pages are limited to "/docs" or "/" and we might not want to mess master branch.

I created a repository, rv32emu-demo, and specify @ChinYikMing as the administrator. Please follow the way how rv32emu-bench works.

I would like to leverage a GitHub action workflow to deploy wasm application to rv32emu-demo.

The GitHub action workflow plan: detect if assests/html/index.html or assets/js/pre.js is modified after a pull request merged. If yes, build and deploy new wasm application to rv32emu-demo. If these two files are not modified and we want to deploy manually, we can use the workflow_dispatch. Consequently, rv32emu-demo would be updated with latest code base.

ChinYikMing commented 5 months ago

So far as I know, there are two main ways to execute WebAssembly programs, one is JavaScript interpreter (NodeJS or Browser JS engine), second is wasm interpreter (e.g., wasmtime). I think you want the least dependency for deployment?

Identifying web browsers like Chrome as necessary for running Emscripten-generated programs is practical. My aim is to establish a straightforward setup for those interested in exploring WebAssembly translation within common macOS or GNU/Linux environments.

Since "coi-serviceworker.js" solves the security response headers issue, we could temporarily require a specific version of Chrome installed and provide a Makefile target to host the WebAssembly in local environment without any headache configuration of web servers.

jserv commented 5 months ago

Since "coi-serviceworker.js" solves the security response headers issue, we could temporarily require a specific version of Chrome installed and provide a Makefile target to host the WebAssembly in local environment without any headache configuration of web servers.

Can you detect the vendors and versions of web browsers, so that we can ensure TCO is supported?

ChinYikMing commented 5 months ago

Since "coi-serviceworker.js" solves the security response headers issue, we could temporarily require a specific version of Chrome installed and provide a Makefile target to host the WebAssembly in local environment without any headache configuration of web servers.

Can you detect the vendors and versions of web browsers, so that we can ensure TCO is supported?

Yes, according to the supported Feature Extensions of WebAssembly in each popular web browser, we can detect the MAJOR version of web browsers which support the TCO. For example, Chrome with MAJOR 112 and Firefox with MAJOR 121 supports TCO.

jserv commented 5 months ago

according to the supported Feature Extensions of WebAssembly in each popular web browser, we can detect the MAJOR version of web browsers which support the TCO. For example, Chrome with MAJOR 112 and Firefox with MAJOR 121 supports TCO.

It sounds great. Please send pull request(s) which detects TCO support and decides if the wasm programs should be loaded or not.

jserv commented 4 months ago

This task is considered completed.

sysprog21 / rv32emu

Run rv32emu inside web browser via WebAssembly translation #75