i-net-software/JWebAssembly

Support for native methods

Horcrux7 opened this issue · 12 comments

WebAssembly supports many features that can not handle directly via Java syntax. To support this we need a syntax extension. This can be important for writing a library.

Please write suggestions and comments to this issue.

Annotation @WasmBinaryCode

Set the final binary bytes directly via a annotation to a method.

@WasmBinaryCode( { 0x23, 0x56 } )
public static int foo() {
   ...
}

Pro

  • You can insert any bytecode without validation. With this you can use also not supported features.
  • for testing via JUnit or debugging of your code you can write an alternative Java implementation.

Conta

  • Never can read this code
  • maintenance is very difficult
  • the creation of the sequences need third party tools
  • work not together with the text output
  • can use only one return parameter

Annotation @WasmCodeBuilder

Use the the API for the intermediate code that also use the JWebAssembly compiler.

@WasmCodeBuilder
public static int foo() {
   ...
   instructions.add( new WasmNumericInstruction( NumericOperator.and, ValueType.i32, 0  ) );
}

Pro

  • this work with binary and text format
  • you can use all features that JWebAssemby support
  • validation via Java compiler
  • no third party tool is needed

Contra

  • the API is not very stable yet. It would make internal structure to a public API.
  • can use only one return parameter
  • No JUnit support or debugging inside a Java IDE is possible because there is no alternate Java code

Annotation @WasmTextCode

Write a WebAssembly text notation code as annotation to a function.

@WasmTextCode( "get_local 0 get_local 1 i32.add" )
public static int foo() {
   ...
}

Pro

  • this work with binary and text format
  • you can use all features that JWebAssembly supports
  • for testing via JUnit or debugging of your code you can write an alternative Java implementation.
  • it is well understandable for the writer of the code because it is a standard

Contra

  • a separate parser for the text format is needed with all the possible errors
  • can use only one return parameter
  • you can use only the features of the parser and JWebAssembly

There is an annotation @WasmTextCode.

And some native APIs was implement with it.

Just curious. In the ReplacementFor classes, why not, instead of this:

    @Replace( "java/lang/Double.doubleToRawLongBits(D)J" )
    @WasmTextCode( "local.get 0 i64.reinterpret_f64 return" )
    static long doubleToRawLongBits(double value) {
        return 0; // for Java compiler
    }

do this?

    @Replace( "java/lang/Double.doubleToRawLongBits(D)J" )
    @WasmTextCode( "local.get 0 i64.reinterpret_f64 return" )
    static native long doubleToRawLongBits(double value);

Seems like this is exactly what native was designed for.

You are right. Can be historian reasons or a simple mistake. You should make a pull request for it.

Oops, I see now that the code I was looking at is obsolete

In master there is only one remaining instance in test class CallFunctions.java:

diff --git a/test/de/inetsoftware/jwebassembly/runtime/CallFunctions.java b/test/de/inetsoftware/jwebassembly/runtime/CallFunctions.java
index 4d7d453..2d0c329 100644
--- a/test/de/inetsoftware/jwebassembly/runtime/CallFunctions.java
+++ b/test/de/inetsoftware/jwebassembly/runtime/CallFunctions.java
@@ -86,8 +86,6 @@ static float nativeCall() {
                         + "local.get 1 " //
                         + "f32.max " //
                         + "return" )
-        private static float nativeMax( float a, float b) {
-            return Math.max( a, b );
-        }
+        private static native float nativeMax( float a, float b);
     }
 }

Not sure if that's there for a special reason or not... kindof looks like it.

I does not understand what you means. First you referenced to https://github.com/i-net-software/JWebAssembly-API/blob/master/src/de/inetsoftware/jwebassembly/api/java/lang/ReplacementForDouble.java

There it is possible to change to a native method. Now you referenced to a unit test which test @WasmTextCode annotation. I can also not find the change set which you referenced. The method nativeMax was never native.

Yes I am confused too... :)

OK duh, I checked out the wrong project (JWebAssembly instead of JWebAssembly-API).

That patch above applies to the JWebAssembly project (if correct).

I will create a separate pull request for the JWebAssembly-API project.

Thanks.

Sorry for the confusion. The first project is the compiler. And the second one is the runtime API (one of several possible APIs).

What can I improve to avoid such confusion in the future?

Hah - nothing. My fault, not yours :)