<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div class="moz-cite-prefix">Reply in line...<br>
On 01/11/2022 13:02, 何伟凯 wrote:<br>
</div>
<blockquote type="cite" cite="mid:3c970cf9.ba77.18433126fd4.Coremail.weikai@isrc.iscas.ac.cn">
Thanks for your attention.<br>
<br>
flw will alter the bits being copied and it will be invalidated if
we copy a float data with fld. When flw load a 32-bits float value
into a 64-bits register, it will fill upper 32 bits of the
register, however, fld will not. Hence, using fld or flw depend on
whether float or double is placed in the return buffer.<br>
</blockquote>
What I suggest is to write the right bit pattern for the whole
register to the buffer in the Java code (including the upper 32 bits
for floats), and then just copy the bits from the buffer to the
register in the VM code. Either with fld or another instruction that
doesn't modify the bits.<br>
<blockquote type="cite" cite="mid:3c970cf9.ba77.18433126fd4.Coremail.weikai@isrc.iscas.ac.cn">
<br>
Our modification is based on openjdk/jdk repo, because we would
like to merge our code into the main stream. We have noticed
changes in the panama-foreign repo, we also think the new
VMStorage class will very helpful for solving the question. When
the change merge into main stream of openjdk/jdk, we will follow
it up.<br>
</blockquote>
<p>We are in the processes of moving all the changes in the
panama-foreign repo to the openjdk/jdk repo for JDK 20. I haven't
made the PR with most of the VM changes yet, but it will be based
on the main PR for the JEP [1]. There are also some last-minute
changes that will likely be added to the main JEP PR [2]. So, to
avoid having to review things twice, I suggest basing the riscv
port on the code in the panama-foreign repo for now, and then
integrate into the mainline repo after the changes from the
panama-foreign repo have been moved there.</p>
<blockquote type="cite" cite="mid:3c970cf9.ba77.18433126fd4.Coremail.weikai@isrc.iscas.ac.cn">
<br>
We look forward to your further suggestions.<br>
</blockquote>
<p>I can take a look at the code once the PR goes up.</p>
<p>Jorn</p>
<p>[1]: <a class="moz-txt-link-freetext" href="https://github.com/openjdk/jdk/pull/10872">https://github.com/openjdk/jdk/pull/10872</a><br>
[2]: <a class="moz-txt-link-freetext" href="https://github.com/openjdk/panama-foreign/pull/750">https://github.com/openjdk/panama-foreign/pull/750</a><br>
</p>
<blockquote type="cite" cite="mid:3c970cf9.ba77.18433126fd4.Coremail.weikai@isrc.iscas.ac.cn">
<br>
WeiKai He<br class="Apple-interchange-newline">
<br>
<br>
<br>
<br>
<blockquote name="replyContent" class="ReferenceQuote" style="padding-left:5px;margin-left:5px;border-left:#b6b6b6 2px
solid;margin-right:0;"> <br>
<p> Hello, </p>
<p> 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.<br>
<br>
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? </p>
<p> 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]. </p>
<p> Jorn </p>
<p> [1]: <a class="moz-txt-link-freetext" href="https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign/blob/foreign-memaccess*2Babi/src/hotspot/share/prims/vmstorageBase.inline.hpp*L43__;JSM!!ACWV5N9M2RV99hQ!IRN0FwuEVD3VWdh8KcgGWQ2QbjUx4l12MEy0b9-DZickSOF11M6lBm6M6FDqbnl6NYoEY9nJIMj0oxxfmL6GWpE$" moz-do-not-send="true">https://github.com/openjdk/panama-foreign/blob/foreign-memaccess%2Babi/src/hotspot/share/prims/vmstorageBase.inline.hpp#L43</a>
</p>
<div class="moz-cite-prefix"> On 30/10/2022 13:44, 何伟凯 wrote:<br>
</div>
<blockquote type="cite" cite="mid:54bf4dd6.610b.18428ebfee6.Coremail.weikai@isrc.iscas.ac.cn">
<pre style="word-wrap:break-word;" wrap="soft">## 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] <a target="_blank" href="https://urldefense.com/v3/__https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc__;!!ACWV5N9M2RV99hQ!IRN0FwuEVD3VWdh8KcgGWQ2QbjUx4l12MEy0b9-DZickSOF11M6lBm6M6FDqbnl6NYoEY9nJIMj0oxxfcMYlDXk$" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc</a> [2] <a target="_blank" href="https://urldefense.com/v3/__https://github.com/feilongjiang/jdk/tree/riscv-foreign-api__;!!ACWV5N9M2RV99hQ!IRN0FwuEVD3VWdh8KcgGWQ2QbjUx4l12MEy0b9-DZickSOF11M6lBm6M6FDqbnl6NYoEY9nJIMj0oxxf2M3LPtI$" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/feilongjiang/jdk/tree/riscv-foreign-api</a></pre>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>