Quote
It looks like you guys in the thread have already figured it out: someone will need to write a scrypt-aarch64.S file for everything to work smoothly.
Alternatively, I could probably have the wallet fall back to a C++ implementation on unsupported architectures. It would just need to be transparent to the users that their architecture does not perform as well as it might with its own assembly implementation. (That is to say that the performance would be really bad compared to a native solution.)
Speaking of performance hits, though, I'm pretty sure one could the ARM version of QEMU to run a 32-bit binary if you just want to run the wallet on an arm64 board. At least until a more robust solution is found. A guide for setting QEMU up on a Raspberry Pi can be found here, but I'm not sure how well that translates to ODROID's boards. You might have to set up ODROID's boards for virtualization (if they support it) and compile QEMU yourself to get things working.
need scrypt-aarch64.S for it to really be a solution ...Alternatively, I could probably have the wallet fall back to a C++ implementation on unsupported architectures. It would just need to be transparent to the users that their architecture does not perform as well as it might with its own assembly implementation. (That is to say that the performance would be really bad compared to a native solution.)
Speaking of performance hits, though, I'm pretty sure one could the ARM version of QEMU to run a 32-bit binary if you just want to run the wallet on an arm64 board. At least until a more robust solution is found. A guide for setting QEMU up on a Raspberry Pi can be found here, but I'm not sure how well that translates to ODROID's boards. You might have to set up ODROID's boards for virtualization (if they support it) and compile QEMU yourself to get things working.
scrypt-arm.S is taken from pooler cpuminer ([email protected]) and he said:
Quote
As documented, there is no Aarch64 implementation in cpuminer.
I do plan to add one in the future, time allowing.
I do plan to add one in the future, time allowing.
I'm also working with OKtoshi on ROKOS for aarch64 however he does not have a board yet ...
https://bitcointalksearch.org/topic/m.14308714
I'll bet DMD foundation would post a bounty for someone to create src/srcypt-aarch64.S
here is src/srcypt-arm.S as a starting point: https://github.com/DMDcoin/Diamond/blob/master/src/scrypt-arm.S
With the release of RPi 3 out and PINE64+ imminent, there is going to be a large demand for aarch64 support.
I'm lucky to have got the Odroid C2 board, they are sold-out till mid-April. Specs are quite similar on all Only the Odroid C2 has 2 GHZ though
I PM'ed pallas too but have not got a reply, he's into stuff like this I think ...
Should PM wolf0 too
By the way, who is DMD wallet dev nowadays ... used to be danbi but we don't hear from him much at all ...
another review:
http://www.jeffgeerling.com/blog/2016/review-odroid-c2-compared-raspberry-pi-3-and-orange-pi-plus
@feldenthorn
If you can give me example C++ code for maybe I can create aarch64 assembly code from it (I have been looking at several arm 32 bit to aarch64 sites), may not be optimized to the max but just need to get wallet to build for now. Hell of a way to learn LOL.
I can probably do a side-by-side C++ to assembly code and later tune it with loop un-rolling etc.
u could put C++ fallback code for scrypt_core() in scrypt_mine.cpp, this is where it is used and defined as extern "C".
