3

Can any one point in the right direction to research, develop, and read up on coding assembly for Monero. I've tried running various distros on the PS3 with no luck. CMAKE has to be up to date to a certain version and isn't supported by Fedora 12 etc since it's an older distro. The PPC64 platform doesn't seem to matter. What seems to matter is the assembly being coded in SIMD.

So I am looking to code and port it myself. I was able to get Litecoin on a PS3 but it is no longer profitable on Fedora 9 with 'cpuminer'. But Monero would seem to be on a PS3. I realized that it is simply a matter of porting Monero's code to assembly to an older version since cross compiling has not seemed to work at all. In others I want to code the functions myself into a workable form of assembly for a PS3. But I do not know where to start when it comes to porting the SIMD assembly for monero itself. Any one know where to go about cross referencing such source code? I basically want to code my own miner. Please and thank you.

user36303
  • 34,858
  • 2
  • 57
  • 123
DragonSonix
  • 41
  • 3
  • For the record, there is a default C implementation of Cryptonight in Monero, so you'd need to port the asm only once the rest works. – user36303 May 19 '18 at 16:06
  • Ive been thinking of doing the same thing. Ive tried compiling xmr-stak-power which almost worked but got an error. Ive been trying to get a cluster going to emulate a different architecture to see if i can still mine a decent amount of monero. But no luck yet as things become tedious. There is a site that will translate any code into assembly online. Google 'compile explorer'. Or 'online compiler assembly translater'. I would get this done but I dont know where to start or finish with this. The PS3 would be great for alt coins as I think they are the future since bitcoin is only going to incr – Allan Sanchez Sep 05 '18 at 01:31

2 Answers2

1

Just so all you testers know. I finally got my PS3's to mine crypto besides litecoin and bitcoin. Unfortunately the hashrate through put isn't impressive like we all already knew. But I am confirming that I get an average of 80 H/S or so per system for Monero. Just in case any one was wondering.

How I did this: One must load NFS and SSH on the clusters nodes of PS3's with Fedora 9. Then one must have a linux capable laptop or desktop as their Master Node to compile and run OpenMPI. Which is open source cluster software. The PS3 can not compile alt-coin miners but will mine through OpenMPI and one's master node as a node on a cluster. So IT IS still possible to mine with them but the hash rate isn't remarkable. Any ways good night. I hope this help some body and good luck!

DragonSonix
  • 41
  • 3
0

Porting the crypto to work on PPC (Big Endian) will not be trivial as it's all been optimized for x86-64 (Little Endian). The code that would need porting can be found at: https://github.com/monero-project/monero/tree/master/src/crypto.

jtgrassie
  • 19,111
  • 4
  • 14
  • 51
  • @user36303's comment on the original question is misleading. Whilst much of the crypto specific code is implemented in C, a huge amount of that code is byte order dependent. There is actually very little written in asm, that is not the hurdle to a PPC port, it's the endianess in the crypto math. – jtgrassie May 21 '18 at 10:05
  • Could you give an example to look at please ? – user36303 Aug 17 '18 at 18:18
  • https://github.com/monero-project/monero/blob/master/src/crypto/crypto-ops.c – jtgrassie Aug 17 '18 at 20:08
  • Also every hash algorithm (keccak etc) are x86-64 little endian. E.g. https://github.com/monero-project/monero/blob/master/src/crypto/keccak.c which is from https://github.com/coruus/saarinen-keccak/blob/master/readable_keccak/README.TXT – jtgrassie Aug 17 '18 at 20:22
  • You don't have a line number in your link. I'm asking for some example of code that's little endian only, not types which are little endian. – user36303 Aug 17 '18 at 20:35
  • There is soo much. Anywhere where there is type casting / expecting bytes stored in a specific order, for example, is an issue https://github.com/monero-project/monero/blob/b780cf4db1f9dfc49e7f16afc47892a5b40fe68a/src/crypto/crypto-ops.c#L51 because it is doing both (as just one example of many). – jtgrassie Aug 18 '18 at 05:11
  • This example does not appear to be endian dependent. – user36303 Aug 18 '18 at 10:32
  • It's pulling bytes from a byte array and OR'in to an int. It's absolutely endian dependent. It's expecting the bytes in a certain order. – jtgrassie Aug 18 '18 at 12:56
  • Of course it's expecting the bytes in a certain order. That doesn't make it endian dependent. It might help if you think of how a C string is represented in memory, for example. The code will expect the bytes in a certain order for the string to make sense, and yet if (s[0]) == 'a') tests the first character of the string whether you're on a little or big endian architecture. – user36303 Aug 18 '18 at 13:32
  • Sorry but you are not understanding. A char array {0x01, 0x00}; when constructing an int, the order you use them matters. You would get either 1 (LE) or 256 (BE). – jtgrassie Aug 18 '18 at 13:59
  • The function referenced is expecting the number (represented as a byte array - unsigned char*) to be LE. This is the issue at it's core - everything in this file (and others) is working with big numbers in LE byte arrays. – jtgrassie Aug 18 '18 at 14:17