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.
FYI, PR#1.
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 :)