Add support for riscv64

[Ast-x64]

This patch adds support for building on riscv64.

[jpcima]

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.

[paulfd]

Thanks for the PR! Do we have any way to add a CI run for this in some fashion?

[XieJiSS]

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?

[jpcima]

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?

[XieJiSS]

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...)

[redtide]

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.

[redtide]

@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

[XieJiSS]

@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 boostorg/atomic#65

[redtide]

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...

[XieJiSS]

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 :-)