Skip to content
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

Support for native methods #2

Closed
Horcrux7 opened this issue Aug 5, 2018 · 12 comments
Closed

Support for native methods #2

Horcrux7 opened this issue Aug 5, 2018 · 12 comments

Comments

@Horcrux7
Copy link
Member

Horcrux7 commented Aug 5, 2018

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.

@Horcrux7
Copy link
Member Author

Horcrux7 commented Aug 5, 2018

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

@Horcrux7
Copy link
Member Author

Horcrux7 commented Aug 5, 2018

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

@Horcrux7
Copy link
Member Author

Horcrux7 commented Aug 5, 2018

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

@Horcrux7
Copy link
Member Author

There is an annotation @WasmTextCode.

And some native APIs was implement with it.

@archiecobbs
Copy link

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.

@Horcrux7
Copy link
Member Author

Horcrux7 commented Dec 3, 2021

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

@archiecobbs
Copy link

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.

@Horcrux7
Copy link
Member Author

Horcrux7 commented Dec 3, 2021

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.

@archiecobbs
Copy link

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.

@archiecobbs
Copy link

FYI, PR#1.

@Horcrux7
Copy link
Member Author

Horcrux7 commented Dec 4, 2021

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?

@archiecobbs
Copy link

Hah - nothing. My fault, not yours :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants