Panama-FFI API Porting for RISCV64

[Jorn Vernee]

Hello,

The interface between Java and native is in general designed to 
communicate in register values (since it's intended to work with any 
foreign language in theory). Primitive types and the return buffer are 
use to transport the register values. The idea would be for the Java 
code to write the bits with the right semantics into the return buffer, 
for the entire width of the register (64-bits?), and then the native 
code could just copy the bits from the return buffer into the right 
register, without altering them.

But, it sounds like this doesn't work for flw and fld? i.e. they both 
alter the bits being copied in an incompatible way? Or is the problem 
that 2 floats can 'share' a register that would normally be taken up by 
a single double?

Also, please note that the latest state of development is in the 
openjdk/panama-foreign repo on the foreign-memaccess+abi branch. It 
looks like the code you have is based on the openjdk/jdk repo. In the 
latest version in the panama-foreign repo, the use of VMReg is replaced 
by a new class called VMStorage (mirroring the Java class), and it is 
possible to attach a register mask to it which can also be used to 
indicate the width of the register, if needed [1].

Jorn

[1]: 
https://github.com/openjdk/panama-foreign/blob/foreign-memaccess%2Babi/src/hotspot/share/prims/vmstorageBase.inline.hpp#L43

On 30/10/2022 13:44, 何伟凯 wrote:
> ## Summary
>
> In recent, Panama FFI-API has been a preview feature. In many scenarios, the Panama FFI API can replace the JNI to implement native function access. The FFI API provides more secure and convenient access to native functions. The specific implementation of FFI API is related to ARCH and OS. In order to enable RISC V64 to use FFI API, porting is required.
>
> ## Notable Things
>
> Because there are different return value passing convention for special structures like `struct {int, float}` on the RISCV64[1].
>
> When making an upcall, that's calling a Java method from a native function, return value of the Java method will be saved in a segment of stack memory called return buffer, and then riscv backend will transfer the data in memory to `a0` and `fa0`.
>
> The instructions used for data transfer are closely related to correctness. If the field containing in the special structure menteioned above is float, must use 'flw', otherwise, 'fld'. This requires a means to pass the width information of fields to the riscv backend.
>
> Unfortunately, according to my understanding, the current interface does not provide a direct means to pass the width information of struct fields to the riscv backend, so the width information is encoded in other ways. Although this makes the riscv porting slightly different from other arch, it does not make the code more difficult to understand and maintain. For details, see comments in the code[2].
>
> ## Testing
>
> All the tests in jtreg have been passed. Some tests under the user mode of the QEMU may fail, however they can pass on the development board.
>
> ## Reference
>
> [1]https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc  [2]https://github.com/feilongjiang/jdk/tree/riscv-foreign-api
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20221031/da23d398/attachment-0001.htm>