Add support for riscv64
This patch adds support for building on riscv64.
Hi, how certain is the implementation of spin_loop_pause under this modification of atomic_queue?
afaik NOP is a ARM-only hack so far
It's a good idea to submit this upstream first https://github.com/max0x7ba/atomic_queue;
perhaps the author will be able to comment.
A reference is also boost/atomic/detail/pause.hpp, but it doesn't have RISC-V either atm.
Thanks for the PR! Do we have any way to add a CI run for this in some fashion?
Hi @jpcima ,
According to the spec, RISC-V currently does not support HINTs:
No standard hints are presently defined. We anticipate standard hints to eventually include memory-system spatial and temporal locality hints, branch prediction hints, thread-scheduling hints, security tags, and instrumentation flags for simulation/emulation.
I'm wondering that is their any workaround for us to make this package compiles on RISC-V, given that nop can't be used as a hardware HINT?
This solution, if it exists, it's about retaining the lock-free characteristic of the queue structure, yet at the same time have some sort of cpu pause that protects against priority inversion.
is there source code of other lock-free data structures implemented on the RISC-V?
Three-page pdf extracted from the spec: lr-sc.pdf
As provided by the spec, lr.w/d & sc.w/d instructions can be used to construct a lock-free data structure, and the spec also gives a short sample (see the attached file above)
(but I can hardly imagine how to port the package to make it compatible with this lr/sc design...)
Giving the current conflict caused by the repository split, I added the VSTConfig.cmake changes in sfztools/sfizz-ui@3588c3f, so I guess this PR can be closed if #1248 solves the problem.
@XieJiSS do you have some input about the state of this issue? I have no knowledge about this but I notice some discrepancy between this commit and your previous comment
@redtide I think that PR is quite outdated and the situation of RISC-V hardware has improved a lot since then.
I'd suggest reusing the code purposed in https://github.com/boostorg/atomic/pull/65
Oh, you are right, the code has changed in the defs file.
I'd suggest reusing the code purposed in boostorg/atomic#65
Not sure but it's possible that here nobody have knowledge nor machines to test, and so give support, on RISC-V, otherwise this issue would be already solved. PRs are welcome...
Oh, you are right, the code has changed in the defs file.
I'd suggest reusing the code purposed in boostorg/atomic#65
Not sure but it's possible that here nobody have knowledge nor machines to test, and so give support, on RISC-V, otherwise this issue would be already solved. PRs are welcome...
Sure, I'm willing to create a PR in the next few days, most probably during this weekend :-)