Skip to content

Dandelion dev #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 28 commits into from
Jan 8, 2024
Merged

Dandelion dev #3

merged 28 commits into from
Jan 8, 2024

Conversation

leon-thomm
Copy link
Collaborator

@leon-thomm leon-thomm commented Dec 24, 2023

This PR adds

  • minor refactoring of parser
  • some documentation
  • option --no-alloc
  • option --crate-name
  • memory import support

notes on the changes to the code:

  • indirect function returns
    • rWasm used to return a Vec from indirect function calls. If optionno-alloc is given it now uses a new enum which will allocate an upper bound of space needed for the returns on the stack.
  • memory changes
    • When memory is declared imported, a reference to the applicable memory type is required on module creation. The reference type required me to add lifetime annotations.
    • I eliminated the use of Box to keep it "simple" with --no-alloc.
      • A Vec already lives on the heap, and a &mut [u8] can too.
      • But a memory of type mut [u8] (--fixed-mem-size + not imported memory) now necessarily lives on the stack.
    • currently, --no-alloc requires --fixed-mem-size
    • memory should probably be simplified
      • see the new mem_type() function
      • e.g. could define a trait MemoryType
        • notice that for a Vec<T>-like type, T should probably be Sized, which can't be dynamically dispatched (so no MemoryType trait objects)
      • The allocator-api would allow for using a Vec with a custom memory allocator provided by the user, but I wouldn't expect anything to land in stable soon.
  • I made some functions const so they can be used for static definitions.
  • added some comments and subjective styling changes to parser.rs
  • possibly a bugfix in section parsing (see comment in code)
  • [TODO reference]
    • I removed the code causing the problem, but didn't fix the underlying issue.

I think parser.rs really needs some syntactic simplifications but I couldn't come up with a nice solution yet. I did some sanity checks but didn't test thoroughly, I think rWasm should get some CI tests.

and I changed how the names section parser reads the type, while the original implementation seems correct under the current number of subsection types, run!(32) is confusing because it should really only read one byte
I saw no good reason why some parsers should be defined within the generate! macro, and others not. For simplicity, I moved them all outside.
not a cosmetic change, will redo on another branch
Eliminates all uses of alloc::Box and alloc::Vec when --no-alloc is chosen.

The main difficulty with removing Vec is the fact that wasm functions have multi-returns, so when calling indirect we don't know how many returns come back.

This commit solves it by allocating as much space on the stack as needed for the highest possible number of returns when calling indirect.

There are other non-stack-based solutions, especially the tinyvec crate allows static heapless vector functionality without usage of unsafe.
makes it a lot nicer to consume the rWasm output from another program
Turns out we only need a panic handler in no_std crates if they are dynamic libraries, which shouldn't be necessary for the crate generated by rWasm.
This makes WasmModule::new() const, which allows for static initialization, which is important in heap-less environments.

It also makes access functions to global constant exports const, so global export constants can also be statically accessed, which is often useful as well.
will need this for incoming changes
This option allows passing a bytes array slice to the wasm module which will be used for the wasm memory. Since this must have a fixed size, this is currently only possible in combination with --fixed-mem-size.

Such a reference to an external chunk of memory requires lifetime annotation, which is a bit messy in the printer, I might try to come up with a macro which relaxes syntax boilerplate for code generation.
the option is implicit if the WASM module imports its memory
@leon-thomm leon-thomm marked this pull request as ready for review January 5, 2024 12:21
@leon-thomm leon-thomm merged commit 3d64253 into main Jan 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant