4 ms·

There's always RISC-V :) Nothing wrong with it, or anything preventing it to be just as fast. The only thing it doesn't have yet is a standardized vector-extens

There's always RISC-V :) Nothing wrong with it, or anything preventing it to be just as fast. The only thing it doesn't have yet is a standardized vector-extension, but it's probably pretty close. We just need JIT support for an embeddable RISC-V emulator, and we're golden. Does it matter what the host language is these days server-side? I suppose there's a higher chance that the WebAssembly standard will adopt some instructions that favor cloud computation now, with these news.

chubot 6y ago
Hm interesting idea... but - wasm has modules, "imports", and "exports" for I/O and host communication. The glue is one of the harder parts of the problem. - wasm bytecode is sandboxable with a simple MMU mapping. That's one reason it has structured control flow rather than goto. (And this is why you need a special algorithm to compile C gotos to wasm.) RISC V certainly doesn't limit itself like that. So I think this idea is glossing over a lot of details... not all ISAs are equal, especially ones meant to be transmitted over the network!
- fwsgonzo 6y ago
  I don't completely understand your second point there, because I'm not necessarily talking about full-system emulation. Just userspace emulation. So, why can't RISC-V be a sandbox? It's just loading a normal ELF into a virtual memory. The first point is news to me, but I suppose you can build anything you want in an open ISA too. It looks like each object is like a shared object with an import and export table that connects things together, so the host would have to have a "modern" variant of a dynamic loader. It sounds like it would be painful to support that without an established way of doing it, that is standardized. So, guess I agree.
  - chubot 6y ago
    The wasm paper covers these issues, and is short and pretty readable: https://scholar.google.com/scholar?cluster=14979605902538775118&hl=en&as_sdt=0,5&sciodt=0,5 https://scholar.google.com/scholar?cluster=14979605902538775... tl;dr security introduces a lot of design constraints that RISC V doesn't have. section 2.3 on structured control flow: WebAssembly represents control flow differently from most stack machines. It does not offer simple jumps but instead provides structured control flow constructs more akin to a programming language. This ensures by construction that control flow cannot form irreducible loops, contain branches to blocks with misaligned stack heights, or branch into the middle of a multi-byte instruction. These properties allow WebAssembly code to be validated in a single pass, compiled in a single pass, or even transformed to an SSA-form intermediate form in a single pass. Also, wasm is a "Harvard architecture" rather than von Neumann (separate address space for code and data), also for security reasons: section 2.2: Linear memory is disjoint from code space, the execution stack, and the engine’s data structures; therefore compiled programs cannot corrupt their execution environment, jump to arbitrary locations, or perform other undefined behavior. At worst, a buggy or exploited WebAssembly program can make a mess of the data in its own memory. However, wasm also leaves some things to be desired security wise. Buffer overflows in C are still buffer overflows once you compile to wasm, and can be chained in to JS exploits. https://old.reddit.com/r/ProgrammingLanguages/comments/icb9ve/everything_old_is_new_again_binary_security_of/ https://old.reddit.com/r/ProgrammingLanguages/comments/icb9v... If you try to use RISC V in the same contexts, you'll have the same problems. If you have an additional layer of process sandboxing, then those could be mitigated. But then RISC V is not a wasm replacement. Although maybe wasm is hopeless for C code, so you need more sandboxing anyway, so then it's on par with RISC V... interesting question.
    - fwsgonzo 6y ago
      You don't have to have the executable code in-memory for RISC-V emulation.
    - seg_lol 6y ago
      I think if you did RISC-V you would have to convert asm -> wasm so that you could recover the CFI information. You can send anything down the wire to the wasm env provided 1. It can instantiate wasm itself 2. Your (whatever) to wasm compiler is small enough and outweighs the downsides of on device compilation (to wasm)
  - whizzter 6y ago
    Had an idea of trying to "script" things for games, the idea was to use a the WASM backend of a regular C/C++ compiler to generate code that could be loaded dynamically and share structures (ignoring sandbox for this) so that testing could be done seamlessly, sadly WASM seems to be 32bit for the time being (atleast for Clang, dunno about GCC but that has other issues), also looked at Risc-V and missing export/import tables looks like it could make things far more complicated (might still try using Risc-V though since i'm thinking of generating syscall tables automatically along with Elf-loading)
    - fwsgonzo 6y ago
      Sounds awesome. I have some abstractions for making interfacing easier, but I don't have any auto-generated structures. https://github.com/fwsGonzo/rvscript https://github.com/fwsGonzo/rvscript I have done that here. Example: APICALL(api_math_smoothstep) { auto [edge0, edge1, x] = machine.sysargs <float, float, float> (); x = std::clamp((x - edge0) / (edge1 - edge0), 0.0f, 1.0f); machine.cpu.registers().getfl(10).set_float(x * x * (3 - 2 * x)); return 0; } "machine" is an argument to each system call handler, so you can have multiple machines for many purposes. For example, I suspect you can use a machine as a savegame - because they are serializable.
      - whizzter 6y ago
        Oh! So the emulator i was looking at was yours, it looked damn nice for just this task and i guess i know why now :D Good choice on using var-arg-templates for passing arguments between env and host, i think moving over all scripting bindings to va-templatized bindings is the only sane option for the future (boy have i spent time fighting binding bugs in my days)
syrusakbary 6y ago
I think WebAssembly still has a bright future, regardless of a corporation practically gaining control over a standard (there's always opportunity for more standards). Here's a nice comparison between WebAssembly and RISC-V, written by Heyang (from the Wasmer team) that fits perfectly on the topic: https://medium.com/@losfair/a-comparison-between-webassembly-and-risc-v-e8fb9d37e6cc https://medium.com/@losfair/a-comparison-between-webassembly...
- jhallenworld 6y ago
  I wonder which leads to a faster emulated machine?
  - FullyFunctional 6y ago
    Assuming the same implementation effort & skill: WASM, hands down (disclaimer: I have significant RISC-V experience and am an stout advocate, but RISC-V is a poor replacement for WASM). ADD: a few of the reasons: - When JITing RISC-V you cannot tell which are the last use of registers without a very expensive whole-graph analysis. Without that, you will have to generate more code than necessary. - WASM's representation is very close to what you want in the compiler. In particular, you can directly tell all incoming control-flow edges, which makes analysis much more precise, gives optimization opportunities you would otherwise miss. Recreating this information from a binary is either impossible (due to computed branches) or expensive both in terms of analysis and the guards you have to generate to protect your assumptions.
    - jacobush 6y ago
      Your comment made me idly wonder if there's a way to make an ISA which lends itself both to fast (even for low-gate implementations) hardware, and to fast JIT-ing.
      - FullyFunctional 6y ago
        I suspect these are conflicting goals but an interesting question. My idle pondering are on ISAs that minimize the challenges in wide superscalar OoOE.
nullifidian 6y ago
RISC-V is from a significantly differing category. A category for WASM doesn't really exist yet, there is nothing else like this -- a relatively low level bytecode language with high-level features such as nominal types, garbage collection, modules.
- xuejie 6y ago
  IMO such a category existed for quite a long time, JVM and .NET all falls into this category. Yes WASM has its fame for becoming a browser standard, but fundamentally, there is very little difference between WASM and JVM.
  - nullifidian 6y ago
    JVM has objects as the basic building block. For WASM it's linear memory(ies), so it's lower level, and was created from the start to support languages like C/C++. .NET indeed looks quite similar, given that it supports C++ compilation, tough I'm not familiar enough with the compilation model to draw comparisons.

chubot 6y ago

Hm interesting idea... but - wasm has modules, "imports", and "exports" for I/O and host communication. The glue is one of the harder parts of the problem. - wasm bytecode is sandboxable with a simple MMU mapping. That's one reason it has structured control flow rather than goto. (And this is why you need a special algorithm to compile C gotos to wasm.) RISC V certainly doesn't limit itself like that. So I think this idea is glossing over a lot of details... not all ISAs are equal, especially ones meant to be transmitted over the network!

fwsgonzo 6y ago
I don't completely understand your second point there, because I'm not necessarily talking about full-system emulation. Just userspace emulation. So, why can't RISC-V be a sandbox? It's just loading a normal ELF into a virtual memory. The first point is news to me, but I suppose you can build anything you want in an open ISA too. It looks like each object is like a shared object with an import and export table that connects things together, so the host would have to have a "modern" variant of a dynamic loader. It sounds like it would be painful to support that without an established way of doing it, that is standardized. So, guess I agree.
- chubot 6y ago
  The wasm paper covers these issues, and is short and pretty readable: https://scholar.google.com/scholar?cluster=14979605902538775118&hl=en&as_sdt=0,5&sciodt=0,5 https://scholar.google.com/scholar?cluster=14979605902538775... tl;dr security introduces a lot of design constraints that RISC V doesn't have. section 2.3 on structured control flow: WebAssembly represents control flow differently from most stack machines. It does not offer simple jumps but instead provides structured control flow constructs more akin to a programming language. This ensures by construction that control flow cannot form irreducible loops, contain branches to blocks with misaligned stack heights, or branch into the middle of a multi-byte instruction. These properties allow WebAssembly code to be validated in a single pass, compiled in a single pass, or even transformed to an SSA-form intermediate form in a single pass. Also, wasm is a "Harvard architecture" rather than von Neumann (separate address space for code and data), also for security reasons: section 2.2: Linear memory is disjoint from code space, the execution stack, and the engine’s data structures; therefore compiled programs cannot corrupt their execution environment, jump to arbitrary locations, or perform other undefined behavior. At worst, a buggy or exploited WebAssembly program can make a mess of the data in its own memory. However, wasm also leaves some things to be desired security wise. Buffer overflows in C are still buffer overflows once you compile to wasm, and can be chained in to JS exploits. https://old.reddit.com/r/ProgrammingLanguages/comments/icb9ve/everything_old_is_new_again_binary_security_of/ https://old.reddit.com/r/ProgrammingLanguages/comments/icb9v... If you try to use RISC V in the same contexts, you'll have the same problems. If you have an additional layer of process sandboxing, then those could be mitigated. But then RISC V is not a wasm replacement. Although maybe wasm is hopeless for C code, so you need more sandboxing anyway, so then it's on par with RISC V... interesting question.
  - fwsgonzo 6y ago
    You don't have to have the executable code in-memory for RISC-V emulation.
  - seg_lol 6y ago
    I think if you did RISC-V you would have to convert asm -> wasm so that you could recover the CFI information. You can send anything down the wire to the wasm env provided 1. It can instantiate wasm itself 2. Your (whatever) to wasm compiler is small enough and outweighs the downsides of on device compilation (to wasm)
- whizzter 6y ago
  Had an idea of trying to "script" things for games, the idea was to use a the WASM backend of a regular C/C++ compiler to generate code that could be loaded dynamically and share structures (ignoring sandbox for this) so that testing could be done seamlessly, sadly WASM seems to be 32bit for the time being (atleast for Clang, dunno about GCC but that has other issues), also looked at Risc-V and missing export/import tables looks like it could make things far more complicated (might still try using Risc-V though since i'm thinking of generating syscall tables automatically along with Elf-loading)
  - fwsgonzo 6y ago
    Sounds awesome. I have some abstractions for making interfacing easier, but I don't have any auto-generated structures. https://github.com/fwsGonzo/rvscript https://github.com/fwsGonzo/rvscript I have done that here. Example: APICALL(api_math_smoothstep) { auto [edge0, edge1, x] = machine.sysargs <float, float, float> (); x = std::clamp((x - edge0) / (edge1 - edge0), 0.0f, 1.0f); machine.cpu.registers().getfl(10).set_float(x * x * (3 - 2 * x)); return 0; } "machine" is an argument to each system call handler, so you can have multiple machines for many purposes. For example, I suspect you can use a machine as a savegame - because they are serializable.
    - whizzter 6y ago
      Oh! So the emulator i was looking at was yours, it looked damn nice for just this task and i guess i know why now :D Good choice on using var-arg-templates for passing arguments between env and host, i think moving over all scripting bindings to va-templatized bindings is the only sane option for the future (boy have i spent time fighting binding bugs in my days)

syrusakbary 6y ago

I think WebAssembly still has a bright future, regardless of a corporation practically gaining control over a standard (there's always opportunity for more standards). Here's a nice comparison between WebAssembly and RISC-V, written by Heyang (from the Wasmer team) that fits perfectly on the topic: https://medium.com/@losfair/a-comparison-between-webassembly-and-risc-v-e8fb9d37e6cc https://medium.com/@losfair/a-comparison-between-webassembly...

jhallenworld 6y ago
I wonder which leads to a faster emulated machine?
- FullyFunctional 6y ago
  Assuming the same implementation effort & skill: WASM, hands down (disclaimer: I have significant RISC-V experience and am an stout advocate, but RISC-V is a poor replacement for WASM). ADD: a few of the reasons: - When JITing RISC-V you cannot tell which are the last use of registers without a very expensive whole-graph analysis. Without that, you will have to generate more code than necessary. - WASM's representation is very close to what you want in the compiler. In particular, you can directly tell all incoming control-flow edges, which makes analysis much more precise, gives optimization opportunities you would otherwise miss. Recreating this information from a binary is either impossible (due to computed branches) or expensive both in terms of analysis and the guards you have to generate to protect your assumptions.
  - jacobush 6y ago
    Your comment made me idly wonder if there's a way to make an ISA which lends itself both to fast (even for low-gate implementations) hardware, and to fast JIT-ing.
    - FullyFunctional 6y ago
      I suspect these are conflicting goals but an interesting question. My idle pondering are on ISAs that minimize the challenges in wide superscalar OoOE.

nullifidian 6y ago

RISC-V is from a significantly differing category. A category for WASM doesn't really exist yet, there is nothing else like this -- a relatively low level bytecode language with high-level features such as nominal types, garbage collection, modules.

xuejie 6y ago
IMO such a category existed for quite a long time, JVM and .NET all falls into this category. Yes WASM has its fame for becoming a browser standard, but fundamentally, there is very little difference between WASM and JVM.
- nullifidian 6y ago
  JVM has objects as the basic building block. For WASM it's linear memory(ies), so it's lower level, and was created from the start to support languages like C/C++. .NET indeed looks quite similar, given that it supports C++ compilation, tough I'm not familiar enough with the compilation model to draw comparisons.