Building the front end without LLVM (WebAssembly, browser) and a host clock for the timers

[s-celles]

Hello,

I am building a free IEC 61131-3 toolchain (Automatellix) that must compile programs in the browser, with no server, and run them in a WebAssembly runtime (wasmi) in the browser and on ESP32 boards. RuSTy is the best basis I found, and I would like to contribute what this use needs rather than keep a fork.

With RuSTy v1.0.5 I verified that:

• plc --target wasm32-unknown-unknown produces WebAssembly objects that link with rust-lld and the standard library built for wasm32 into modules of about 1 KB, which run correctly in wasmi;
• the front end (parser, index, resolver, validation, lowering, plc_xml) builds for wasm32-unknown-unknown once LLVM is optional.

Proposal 1: front end without LLVM

• inkwell and plc_llvm become optional behind a default llvm feature of plc-compiler; default builds do not change;
• get_implicit_call_parameter moves from the expression generator to a small call_parameters module (it is the only link from the resolver and the validation to the code generator); the generator keeps a wrapper;
• the code generator, the code field of the built-ins and the LLVM target helpers are gated with cfg(feature = "llvm");
• plc_driver gets the same feature, so that a front-end pipeline (parse, index, annotate, lower, validate) runs without LLVM.

Other uses: a language server or linter compiled to WebAssembly (VS Code for the web), faster CI checks without LLVM. I have working patches against v1.0.5 and would rebase them on master.

Proposal 2: host-provided clock for TON, TOF, TP

The timers read std::time::Instant, which panics on wasm32-unknown-unknown, and its value changes during a PLC cycle. A feature of the standard library would read the time from a function that the runtime provides (for example an import plc_rt.now_ns on WebAssembly), as runtimes based on MatIEC do with __CURRENT_TIME. It also allows a deterministic simulation in virtual time.

Proposal 3: a small API for diagnostics as data

Diagnostician::with_reporter (a diagnostician with a custom reporter), to collect the diagnostics as data in an editor instead of printing them.

Also found

• The build script of the standard library calls the compiler as a library, so a build of the standard library for another target needs LLVM on the build machine; a mode that uses a prebuilt plc binary would help cross builds.

Questions

1. Would you accept proposal 1, and in which form (feature name, module location)?
2. Is a host clock for the timers acceptable, and do you prefer a feature, a callback registered at start-up, or an import only on wasm32?
3. Later, would a WebAssembly code generator (a second back end next to LLVM, for the browser) be of interest upstream, or should it stay in a separate crate?

All contributions under LGPL-3.0, with tests. Thank you for RuSTy!

Assisted-by: AI (text prepared with AI assistance)

[ghaith]

Hello @s-celles thank you for the interest.

I'd be ok with wrapping llvm behind a default feature, but the current crate structure makes this somewhat harder to isolate into its own crate iirc so it would leak a lot of feature checks into different pipelines (The builtins for example have a codegen part in them). I still think there is benefit from that but based on how invasive the PR might end up being, we might want to devide this into moving the codegen and then applying the features.

I'm also not sure if the webassembly path would require us not to link against llvm? So maybe to understand better, rusty is compiled for webassembly here, and not only compiling for webassembly?
This means the frontend rusty will not be able to produce IR, just run diagnostics (LSP light maybe).

I would welcome a data path for the diagnostics, this was on our todo list for a while but we never got to it. Something like the --json flag that cargo provides but also usable /callable as a library would be great.
Proposal 2: If we can keep it generic i'm open for that.

Regarding 1.0.5 and master, i recommend you rebase the changes on master, we are diverging significantly from the 1.0 branch. 2.0 has different handling of time and ltime, and a new xml parser for CFC that uses the 61131-10 specifications.