Building to WebAssembly

[teksturi]

I just throw out our current idea to use Rusty in our PLC. We have lot of different hardware's to support so we kind of need interpreter so same program would work every hardware. Also we have to think security very carefully.

So now our plan is to target Wasm. Then we will have Rust Wasm runtime which will run IEC Wasm program. In the end we would like to support also 32 bit Wasm but we will start from 64 bit Wasm as I have read that Rusty does not yet support 32 bit mode. I'm also thinking should Rusty actually support this workflow as I think it is really nice way to run IEC with PLC's. This means that even microcontroller could run these programs as you only need to support Wasm runtime.

Also it makes possible that there could be website where it is possible to compile and even run IEC code right on the browser. Like https://wasmer.io/posts/clang-in-browser I love this idea because that makes possible to have online courses.

Don't hold you breath that these things will happened anytime soon as we have couple other more important projects.

Edit: Can be moved to ideas if you see better fit.

[teksturi]

Ok got something to work already. First create simple.st

{external}
FUNCTION puts : DINT
VAR_INPUT {ref}
    text : STRING;
END_VAR
END_FUNCTION

PROGRAM main
    puts('In the main! $N');
    another();
END_PROGRAM

PROGRAM another
    puts('hello, world ^____^ $N');
END_PROGRAM

next generate wasm. We export main and main_instance so we can start this. allow-undefined is there as puts is not defined. no-entry is because we do not have _start and we do not even want that as we want to start this by hand currently at least.

./../../target/debug/plc simple.st --ir
llc-14 -march=wasm32 -filetype=obj simple.st.ll -o simple.o
lld-14 -flavor wasm --export=main --export=main_instance --allow-undefined --no-entry simple.o -o simple.wasm

Now we can run that with Rust using wasmtime.

use wasmtime::*;

fn main() -> anyhow::Result<()> {
    // Wasmtime setup
    let engine = Engine::default();
    let mut store = Store::new(&engine, ());
    let mut linker = Linker::new(&engine);

    // Add puts function. (Very hacky as just POC)
    linker.func_wrap("env", "puts", |mut caller: Caller<'_, ()>, ptr: i32| -> i32 {
        // Get memory from the caller
        let memory = caller
            .get_export("memory")
            .and_then(|e| e.into_memory())
            .expect("missing memory export");

        let data = memory.data(&caller);
        let start = ptr as usize;
        let mut end = start;

        // Scan until null terminator
        while end < data.len() && data[end] != 0 {
            end += 1;
        }

        let slice = &data[start..end];
        match std::str::from_utf8(slice) {
            Ok(str) => print!("{str}"),
            Err(_) => println!("[puts] invalid UTF-8 at {ptr:#x}"),
        }

        // mimicking C puts return
        0
    })?;

    // Load and instantiate module
    let module = Module::from_file(&engine, "simple.wasm")?;
    let instance = linker.instantiate(&mut store, &module)?;

    // Get address of `main_instance`
    let main_instance_addr = instance
        .get_global(&mut store, "main_instance")
        .expect("global main_instance missing")
        .get(&mut store)
        .i32()
        .expect("main_instance is not an i32");

    // Call `main` with that pointer
    let main = instance
        .get_typed_func::<i32, ()>(&mut store, "main")
        .expect("main not found");

    main.call(&mut store, main_instance_addr)?;

    Ok(())
}

It should output following:

In the main! 
hello, world ^____^ 

That main_instance_addr thing is little hacky currently and I did not give any deep toughs for that,

Edit:

One thing we at least would want is that we can attach GDB/LLDB to runtime. So project guy can just enter debugger and get output. That is also interesting problem as we will use Wasm runtime. Have to check it out if that is possible.

[teksturi]

Got even debugging working with LLDB with help of this 1. So we can debug dynamical loaded Wasm file. That is pretty awesome. I have currently only tested that I can do

breakpoint set --file simple.st --line 10

but that is more than enough for so little effort. In the end idea is to use remote debugging 2.

[ghaith]

Hello @teksturi, thank you for the update, I think getting rusty to compile for wasm is a pretty good idea, I also heard from another company that they are interested in getting that support, but for our current small team it is currently out of scope. I would be happy however to review any changes required to get better support.

Regarding 32bit, i think this is something we would also like to support. Currently pointers are set to 64 bit, and date/time types assume 64bit, we would need to rework how these are set, and decide on how the precision change is going to be handled. The standard also requires 64bit sizes, (LINT, LWORD, LDT, LT, LREAL..) which with 32 bit become somewhat problematic but i'm sure this is solvable.

[teksturi]

I think we should not change 64bit date/time even when using 32bit system. At least we use 64 bit date/times already in our 32 bit system.

I tested that every 64 bit operation seems to work on 32 bit system. I did already used DT, pointers, LINT in 32 bit wasm module and everything worked. Are you sure that there is something wrong on Rusty that prevents usage in 32bit systems? It is totally normal to use 64bit datatypes on 32bit systems.

Edit: Checked llvm-ir and it might be that example pointer does not work correctly when doing debugging but as debug information says pointer is 64bit. It is also aligned by 8 which is fine but could be 4 on 32bit systems. Still not so many thinks to change I think.

[ghaith]

Debug is indeed a case to adjust, it's also converting a pointer to a value and doing operations on it. I believe pointer arithmetics would work on a pointer type, but assigning the pointer to an DWORD and vise versa will currently result in a validation error, we should handle such validations based on the architecture type. Also the ADR returns an LWORD currently, this has to be more dynamic.

All in all, a lot might work, it's just currently undefined behavior. Regarding 64 bit types, I'm not sure they would still be consistent on a 32bit system since they no longer fit in a word.
It depends on how llvm translates our addition instructions on a 32 bit system.
Both arm and Intel provide instructions to insure 64bit additions are atomic on a 32bit system according to a quick google search so it might not be a problem after all, it would still be something we should verify.