where can we see the sourcecode and download windows binaries ?
also advice from me compile the miner with mingw it makes the miner software more powerfull.

You should add it to github.

good work

Just checking in. Thread is looking good. I looked threw my collection of CPU miners and everything is pretty old and outdated.
Except the ones you talked about earlier. I'll be reading along and will be ready for this when the time is right, thanks for your support.
I'll have to brush up my Linux skills as most of what I have running at the moment is windows based.

Looking forward to the cpu miner. 
 
I'm willing to help test it.   I've some i-7, I-3, I-5, core 2 computers.
Along with some older various single core Intel & AMD I have sitting here gathering dust.

Also have a black box AMD FX=8320E 8-core.

Algos I'd like to see are : neos, spread X11, Ethereum and the algo XMG coin uses.

--GKar (former nic was Angora)

This is interesting. Been trying to make the cpuminers faster myself but never got much done. To busy with other things. If you need help compiling with mingw I could help.

Good luck 

theLosers106.

Just wondering if the folder's name sse2x6 correct?

I'm looking for opinions on how to handle incompatible CPUs, during the test phase and then the first release

There are two parts to this issue. First is whether the CPU has AES_NI and the second is whether
cpuminer is compiled for that architecture. it's a biggger issue on Windows where the builds are
portable. I hope MS builds to support multiple architectures and select the best one at run time.
When multiple architectures are supported in cpuminer it is my intention to do exactly that.

But for the time being it only support ASES_NI so...

For the first part I'm considering 4 options.

1. If the CPU doesn't support AES_NI exit.
      probably most likely for the release

2. Damn the torpedos full speed ahead
      My preferred choice during testing

3. Add a comand line prompt to choose 1 or 2
        will become obsolete when more architectures are supported
        would probably delay the test release

4. Add a user prompt at startup
       This would require the work in 3 as well additional work to add a yes/no prompt and
       expand the new command line option for 3 choices if an incompatibility is found: Exit, Continue,
       or Prompt(default). This has all the cons of 3 but more so.

I'm not interested in poll, I prefer the reasons for the choice. And of course the beta testers can get what
they want.

Hi Wolf0, thanks for contributing.

I've got the capabilities check working has_aes-ni() already existed and I wrote has_sse2. I'm now trying to get cpuid working to see
if I can display the actual cpu model.

While waiting until I downgrade to VS 2013 let me indulge myself as I ramble on about who I am.

I'm a 58 year old computer geek who was laid off with a good severence package 8 years ago less than
a year before the company went bankrupt.

My education is somewhat limited, just a 3 year computer science diploma. In my final year in college
I and 2 other team members wrote an assembler for a microprosessor board that didn't have one.
It had no keyboard or display interface just an rs-232 serial port. So we had to write the assembler
twice on two different processor architectures. My teammate had an Apple 2e and it could connect
to the serial port and talk to the monitor program. It also had some rudimantary file transfer capability
so off we went. We got it done on tie with only one real all-nighter which was more by choice than
necessity. We were among the few that attended class or stayed awake in class the last week before
the formal project demonstration week. We actually had a live demo where we uploaded source code
to the board comlied it and executed it. And it worked. For a bit of humour we even deliberately
left a coding error so we could show the eror handling capability. They we all three graduated and
ended up at the same company, although at different times and in different departments. The same
company that went bankrupt after giving me a golden parachute. Ifeel sorry for the people layed off
after me because the company started cutting back on the packages. Then they declared bankruptcy
and all severance packages were taken off the table. They even reduced pension benefits to past
employees A real shame.

The proprietary system I worked on used Motorola 68k, 88k and powerpc cpus. I was most familiar with
the unpopular 88k. My claim to fame was discovering a bug in the branch prediction which ironically
improved performance once it was disabled. Apparently the BP conflicted with a compiler optimization
even if it had been working properly. The 88k, Moto's first venture into RISC, however, was short lived.

The software system was an integrated development system consisting of a run time real time operating system,
it's applications, a Linux based (originally IBM mainframe) multi-site program and documentation library,
and compiler all written in and for a proprietary high level language with similarities (ie strict type checking) with Pascal.
I really learned to love the language and it has some great features, with OO added later. One of my favorite quirks
in the language was the guzinta: "->". This is unlike similar c++ operator. It is the assigment operator
and works like this:  "value -> variable;".  Some of your may recognize it.

it had some important features like not defining the null pointer as 0. nul always pointed off to invalid address high
up in the address space. Address 0 was also invalid and would throw an exception if accessed. The languange
also had array index protection built into the compiler. An index out of range also would throw an exception.
There was also a built in data structure (nice to own your own compiler) called a descriptor that was essentially
a pointer to an array. It also had index protection. c++ probably has a class similar to the descriptor but without
index protection. That feature alone made the system so much more resilient to memory corruption and easier
to debug, but most importantly the concept of a buffer overflow did not exist. The compiler would not allow it.
Imagine how many fewer exploits there would have been had c/c++ had such protection (at a slight performance
cost).

I've never done any Linux or c++ development although I had some exposure to c++ at work. Many of the concepts
are so different that what I am familiar with and that slows me down a lot. I've used HP-UX, solaris and linux as
desktop workstations at work and used linux at home since Redhat 5.2.

Although I'm comfortable with assembly code I haven't touched Intel since the 8000 series. That will make the assembly
language files tough to work with. I have a couple of optimization thechniques I've used in the past but they require
intimate knowledge of the Intel architecture such as memory interface, cache organization, execution environment,
instruction issue and retirement throughput, and things I'm probably not aware exist. I have a lot to learn, but that's why
I'm here.

I know nothing about cryptographic algorithms so don't expect me to code new algos. I'll leave that up to others.

I had heard of Bitcoin but didn't get involved until very late (too late) in the darkcoin frenzy in April 2014. I started
with just one CPU but unknown to me at the time ASICS had taken over bitcoin and scrypt was next. And GPUs were taking
over the altcoin algos. I bought a gt730, a nice little card that performed on par with my i7-4790K. I bought a 750ti shortly
after that and a few other cards since then.

Well that's how I got here. I'm bored with lots of time on my hands so I've been poking around at miner code here and there.
I'm even less familiar so I took a shot with a cpuminer and was surprised. It is a credit to Pooler's design that I was able to
pull together code from 3 different miners and make it work smoothly and efficiently in a short time.

VS is still installing but I think it's time for a break.

I must be getting tired I just tried to post this to the wrong thread. I giess i don't have the stamina I did 25 years ago.

Thanks for reading and taking an interest in my project.

An update on the beta test.

Windows is definitely out for the beta test and so is CPU ID display. Arcitecture checking is working but will be
in permissive mode for the test build. I'm pretty beat tonight but will start packaging everything tomorrow.
I will be contacting the select beta testers by PM to make arangements for getting the beta build to
them. I expect it to be available friday. I expect the beta test to be quite short as the software has been
very reliable. I hope the first public release is out next week.