Topic: New demonstration CPU miner available - page 10. (Read 386323 times)

I'm still getting this when trying to compile 1.0.1 on OSX:

Version 1.0.1 is released.

The only change is the addition of OSX build support.  FreeBSD is also reported to be working out of the box.

There is no Windows build for this release (no need).

I have a bitcoind server running and accepting connections aswell (rpcallowip=*).

I have tried to run minerd connecting to my bitcoind server, but all I got is:

# ./minerd -c miner.cfg
[2011-05-14 20:24:41] 8 miner threads started, using SHA256 'sse2_64' algorithm.
[2011-05-14 20:33:41] PROOF OF WORK RESULT: false (booooo)
[2011-05-14 20:34:16] PROOF OF WORK RESULT: false (booooo)

Also, the hash meter on the other side (bitcoind) did not increase at all.
Shouldn't the bitcoind (server) hash meter increase aswell ?

Am I missing something ? Am I 'pooling' wrong ?
I'm running openSUSE 11.3, kernel 2.6.34.8-0.2, i7 930.

Thanks in advance.

Sorry I've missed most of the recent discussion...busy with a new addition...

The r10 "trick" of letting it get clobbered requires you know something about the calling convention of the OS in use. The Linux SSE2 code for x86_64 will completely break on Windows, since there's a different set of registers saved between function calls. Depending on what OSX does with r8, you may be able to let it get clobbered, saving you a cycle or two.

I never really found any docs on how the calling convention works under Darwin/Mac OSX. I'm sure reading the GCC source code would enlighten someone. But I also like my sanity.

I got Mach-O x86_64 SSE2 to work (Mac OS 10.6.7). Here's the list of everything I did:

1. I got the file libcurl.m4 from a curl source tarball and stuck it in an m4 directory.

2. I installed the gnulib byteswap module into the cpuminer directory and updated build scripts as necessary.

3. When configuring, I had to use both "-arch x86_64" in CFLAGS and the '--build=x86_64-apple-darwin10.7.0' flag, since it seems to detect that my kernel is 32 bit rather than that my processor is 64 bit.

4. To assemble sha256_xmm_amd64.asm, I set "-f macho64" in the Makefile (todo: integrate this into configure)

5. To fix the assembly failures, I applied the patch here: .

It fixes the 32-bit offset by using another register to hold the current target, which is then used directly and updated as necessary. This adds one extra line of assembly (I'm not sufficiently familiar with x86_64 assembly to know whether or not it actually adds an extra _instruction_, but it probably does) to the main loop as well as a push and a pop to save and restore the values of the register I used (r8). The assembly already uses r10 without doing a save and restore, but I'm not sure how to check that r8 is unused, so this might be unnecessary. It also fixes a problem where my gcc apparently adds leading underscores to all of the names.

This is the least clean section because it probably breaks the build on Linux. Nobody said assembly was supposed to be portable...

A rename will only be considered if a conflict exists with an existing, real-world program.

Otherwise, you're already looking at a program that's seen six months of heavy use on Windows and Linux, using the "minerd" name.  A rename would create pointless churn, with zero value for existing cpuminer users.

Hi, I like to give some news about the not oficial debian/ubuntu package of bitcoin-cpuminer:

* You can find the version 0.8.1 in ubuntu and debian, only in ubuntu (maverick, natty, oneiric) have SSE2_64 enable.
* If not exist any issue in the last version 1.0, i will create a package in a couple days.
* If possible this package get in the next ubuntu release, please check: https://bugs.launchpad.net/ubuntu/+bug/780258, give you comment's or any feedback.

* @jgarzik: In ubuntu revu get this comment
http://revu.ubuntuwire.com/p/bitcoin-cpuminer


what you think @jgarzik ?

read more ...
https://bitcointalksearch.org/topic/m.115320

Found it on another page in this thread:


Works!

But configure gives me:

Any Idea what is wrong?

Shouldn't the configure script be checking for that, then?

OSX CPU Miner Binary

donations welcome @ 1MBBi4ZXrRaLZWFNrfHSSfTA8S9ZUBeUFD

Thanks xf2_org, I'm now up to gcc 4.3.3

gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)

but now I get

 make
make  all-recursive
make[1]: Entering directory `/home/spoddy/cpuminer-1.0'
Making all in compat
make[2]: Entering directory `/home/spoddy/cpuminer-1.0/compat'
Making all in jansson
make[3]: Entering directory `/home/spoddy/cpuminer-1.0/compat/jansson'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/spoddy/cpuminer-1.0/compat/jansson'
make[3]: Entering directory `/home/spoddy/cpuminer-1.0/compat'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/spoddy/cpuminer-1.0/compat'
make[2]: Leaving directory `/home/spoddy/cpuminer-1.0/compat'
make[2]: Entering directory `/home/spoddy/cpuminer-1.0'
gcc  -O3 -Wall -msse2 -pthread  -o minerd cpu-miner.o util.o sha256_generic.o sha256_4way.o sha256_via.o sha256_cryptopp.o sha256_sse2_amd64.o -lcurl -Wl,-Bsymbolic-functions -lgssapi_krb5 compat/jansson/libjansson.a -lpthread  
cpu-miner.o: In function `miner_thread':
cpu-miner.c:(.text+0xb2e): undefined reference to `ScanHash_4WaySSE2'
collect2: ld returned 1 exit status
make[2]: *** [minerd] Error 1
make[2]: Leaving directory `/home/spoddy/cpuminer-1.0'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/spoddy/cpuminer-1.0'
make: *** [all] Error 2

Is this still a gcc version issue? And what version have others managed to compile on?

Thanks

Do you mean 4way or sse2_64 algorithm?

sse2_64 requires yasm, and a 64-bit machine.

Use a newer compiler.

anyway to support sse2 on ubuntu ?

That is what I get

sha256_4way.s:11221: Error: bad register name `%rbp'
sha256_4way.s:11223: Error: bad register name `%rbx'
sha256_4way.s:11225: Error: bad register name `%r15'
sha256_4way.s:11227: Error: bad register name `%r14'
sha256_4way.s:11229: Error: bad register name `%r13'
sha256_4way.s:11231: Error: bad register name `%r12'

a lot of this when i tried

gcc -c sha256_4way.s

Configure runs ok, but I'm getting a make error, .

sha256_4way.c:51: sorry, unimplemented: inlining failed in call to ‘ROTR’: function body not available
sha256_4way.c:458: sorry, unimplemented: called from here
sha256_4way.c:51: sorry, unimplemented: inlining failed in call to ‘ROTR’: function body not available
sha256_4way.c:458: sorry, unimplemented: called from here
sha256_4way.c:51: sorry, unimplemented: inlining failed in call to ‘ROTR’: function body not available
sha256_4way.c:458: sorry, unimplemented: called from here
make[1]: *** [sha256_4way.o] Error 1
make[1]: Leaving directory `/home/spoddy/cpuminer-1.0'
make: *** [install-recursive] Error 1
spoddy@bob:~/cpuminer-1.0$ cd ../bitcoin-0.3.21/

I'm a *nix newbie so any help would be appreciated.

Version 1.0 release.  See top post for URLs.

Changes:
- jansson 2.0 compatibility
- correct off-by-one in date (month) display output
- fix platform detection
- improve yasm configure bits
- support full URL, in X-Long-Polling header

So which algo is the fastest on teh same intel CPU ?

c or crpto or arypto_asm32 or 4way ?

I have yasm 1.1 and it shows it is ok on ubuntu natty but still no 4way in the compiled minderd.

any help ?