Repository files navigation

WebAssembly for Scala

Provide some AST and a way to convert them to wasm binary. There is also a printer for binary wasm.

There is two way to usewasm, either as a cli or a library.

It's usingsbt for building, simply ensure that you have it.

To ensure that it's working, you may want to runsbt test prior to usingwasm.

It can be used directly from thesbt prompt, there is no system-wide binary installation.

To add to the local ivy storage

sbt publishLocal

and addlibraryDependencies += "default" %% "scalawasm" % "0.1" to yourbuild.sbt

To compile wat file to wasm file

sbt run compile watfile1 watfile2 ...

To print the content of a wasm file

sbt run print wasmfile1 wasmfile2 ...

The main target is to be able to have a library to generate wasm, usable in scala, from a compiler perspective.

The compilation pipeline and data type used at each stage is

pipeline         text.Lexer -> text.Parser -> binary.ToBinaryAst -> binary.ToBinarydatatype    String  ->  ast.Token   ->   ast.Tree     ->     ast.Binary   ->   Stream[Byte]

The most suitable coding entrypoint iswasm.ast.Tree, it provide a convenient, yet nearly binary, tree.

A good code starter is

for {  ast<-Module(    name=Some("My Module"),    funcs=Seq(Function(        sig=Signature.Function(),        instrs=Seq(Opcode.Nop,      ))))  p<-ToBinaryAst(ast)}yieldToBinary(p)

• ToBinaryAst.Section.Export works only for function, it's trivial to port it tosupports others
• ToBinaryAst.getSections could use some refactoring, to nicely separatewhich spaces can be used in which section
• find a good macro system for Scala, to reduce some value duplication inLEB128.Type

• there is structural support for some wasm extension, such has multi return ormulti memory, but it still have to be defined in spec and fullyimplemented/tested
• Data section is implemented untilTree but not in the remaining pipeline
• Custom section is not implemented, there is partial structural support for it
• remove many warning by using dedicated case object instead of having ageneric way to do it

• parser is too simple, it support only "regular" wat, but the specdocumentation is not very precise either, that would need some improvementbased on the new version of the spechaving a better parser would lead to very easy testing, as drop-in of fileswould works, we could reuse directly the core testing suite of the spec repo(there is still some issues, such as them using some undefined opcode)
  • correctly handle multi lines comments
  • parse the full syntax
  • int/float values are badly handle, it will break on some corner cases,also, the parsing is based on naïve understanding (previously undefined);see the "toInt" TODOs
  • there is some structural check we can push to parser, such as i32 can'tload a value bigger that the actual available range
  • order ofmodule opcode is either not well defined or wrong
• Printer can be much cooler than that and try to regenerate the wat inputand having a way to print wasm and also a decompiler
• support other compilers than the reference one
• remove quirks used for spec compatibility, but that would require thatWebAssembly/spec#625 be fixed first; check forConfig.enableSpecCompat