CPUInfo library

[SpooK]

I see there's an OS X section on the board now... If anyone has OS X with an x86 processor, could they please download the latest sources with svn (svn co https://cpuinfo.svn.sourceforge.net/svnroot/cpuinfo cpuinfo), make it, and see if TestCPUInfo works?
I believe OS X also uses gcc, so it probably works just as well as on FreeBSD and linux. But I'd like to be sure, and fix any problems if they occur.

I have 10.5 on a Core 2 Duo, I'll test it some time this week.

[Scali]

On another note... someone told me that ESET NOD32 antivirus says that my Launch3264 executable is a worm.
Must be a false positive. Unfortunate though, it may give the wrong impression when people download CPUInfo or my 3d engine stuff.

[SpooK]

Using the supplied Makefile, it didn't compile with XCode 3:

Code: [Select]

cc -c -o CPUInfo.o CPUInfo.c
CPUInfo.c: In function ‘CPUID’:
CPUInfo.c:404: error: can't find a register in class ‘BREG’ while reloading ‘asm’
make: *** [CPUInfo.o] Error 1

I read up on the error and it has to do with using EBX in position independent code. From what I remember about Mach-O, it uses a technique similar to ELF's GOT for PIC, so an issue with using EBX sounds feasible.

I had to change the following in CPUInfo.c around line 404:

Code: [Select]

__asm ("cpuid"
: "=a" (pRegs->eax), "=b" (pRegs->ebx), "=c" (pRegs->ecx), "=d" (pRegs->edx)
: "a" (index)
);

... to this...

Code: [Select]

__asm ("cpuid"
: "=a" (pRegs->eax), "=S" (pRegs->ebx), "=c" (pRegs->ecx), "=d" (pRegs->edx)
: "a" (index)
);

... and then it compiled fine.

I ran TestCPUInfo and attached the results to this thread.

[Scali]

Hum, that is a problem... I can't stop cpuid from using the ebx register.
As you can clearly see from the processor brand string, the 4 characters that should come from ebx are now garbled (they are read from esi instead of ebx).
Perhaps the answer is to add ebx to the clobber list of the __asm statement... Weird that it didn't complain about that on linux/FreeBSD though... they all use gcc, and technically ebx is a non-volatile register. Then again, a perfectly valid __asm block in a .cpp file suddenly caused errors when I moved it to a .c file, so who knows what logic or lack thereof is in gcc and its handling of __asm blocks

Thanks for testing anyway.
It looks like the clockspeed is also wrong, by the way.

Edit: Could you try to put the =b back, and surround the code with a push %%ebx and pop %%ebx? That might make gcc see that the register is preserved.

[Scali]

It appears that the problem is caused by the -fPIC flag of gcc. PIC stands for Position Independent Code. It uses ebx to make the code position-independent (only in 32-bit mode, 64-bit mode probably uses RIP-relative addressing).
Apparently the Apple environment has -fPIC enabled by default.
I've added a workaround for the cpuid instruction. It should now compile right away, and also report the proper string and all that.

[Scali]

Come on, don't be shy... I know I've been neglecting the assembly programmers. I still haven't gotten round to including a .inc file for MASM users.
I'm going to fix that tonight.
I will also put a new 0.4a release together, since the problem with Mac OS X was solved a while ago, the Dependencies project is now in a workable state, and I've added separate VS2005 and VS2008 projects to all code.
While I'm at it, I should also include a changelog, because so far there hasn't been an overview of developments with the releases.
I should also start using SVN tags to indicate which files belong to which release. Perhaps I should also create source code branches everytime I build a new release.
I have neglected to do that so far, so it's not very easy to track developments back to releases. Mostly a cosmetic issue, since it's such a small project at this stage, but still... better to get everything right, and use the experience for future updates/projects aswell.
Another thing I should do perhaps is to create a custom flag for 64-bit or 32-bit, rather than testing _M_X64 and __x86-64__ in every place (both MSVC and gcc flags).
Perhaps it's better to just have one #ifdef _M_X64 or __x86-64 #define 64bit, and then test only for 64bit in the actual code.

Out of interest: is anyone actually interested in using the library? Could be in any shape or form.

[Scali]

Okay, I've been messing about with SVN... took a few more revisions than absolutely necessary I suppose, but I got it in the end...
I now have a /trunk and a /tags directory.
I've tracked down the revisions from which I made the original releases, and created tags for each release.
The main code is now moved from the root directory to the /trunk subdirectory.
I've also added a CHANGELOG.txt to the project.

I haven't had time to do a .inc file yet, and I want to do another few small tweaks to the code, and then 0.4a release.

[Scali]

CPUInfo 0.4a release is here:
http://sourceforge.net/projects/cpuinfo/files/

Changelog for Release 0.4a:
- Added CHANGELOG.txt to keep track of changes between releases
- Converted library code to basic ANSI C.
- Introduced CI_BOOL/CI_TRUE/CI_FALSE to make the code a bit more readable for plain C.
- Introduced CI_X64 flag to have compiler-specific flags only in the header.
- Added include files for MASM.
- Fixed inline asm for gcc, now also works with -fPIC option, and in 64-bit.
- Dependencies code is now functional, with the exception of SxS support.

[ti_mo_n]

It incorrectly says that my Core 2 Duo supports Hyper Threading.

I have Core 2 Duo, Family 6, Model 15, Stepping 11, Revision G0.

[Scali]

It incorrectly says that my Core 2 Duo supports Hyper Threading.

I have Core 2 Duo, Family 6, Model 15, Stepping 11, Revision G0.

No, that is correct. Every CPU since the Pentium 4 will report the HyperThreading flag. You have to compare the number of physical cores to the number of logical cores to determine whether HyperThreading is enabled.

[ti_mo_n]

Oh, sorry, I thought this has already been processed. OK, so the app works correctly, then.

[Scali]

Oh, sorry, I thought this has already been processed. OK, so the app works correctly, then.

Yea, it's a tad inconvenient... Problem is that CPUID can't give you that information (well, on Nehalem you can, with index 0Bh). I think you need to use APIC to get the number of physical CPUs. And that probably means that you'll need to use OS-specific functions.

If you want to know how it's done, here is an article and example code from Intel:
http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/

Since Vista, Windows also has a GetLogicalProcessorInformation() API, which is easier.

[Scali]

I just got this email:

Software Downloads

Dear Sir/Madam

Softoxi.com lab testing team would like to inform you that your product CPUInfo has been listed and awarded by our editors:
----------------------------------------------------------------
CPUInfo is a simple freeware library created for determining CPU features, specs and related OS properties in an easy and unified way, among a wide range of CPUs and OSes.

The developers can use it as information (eg log/debug), and to select optimum codepaths at runtime.

The CPUInfo library is open source and free to use and modify under the BSD license.

CPUInfo includes a handy test application that displays some of the main features. The sourcecode can be studied to find out how to use the CPUInfo library and how to extract the information you are interested in, for use in your own applications.
----------------------------------------------------------------

After carefully testing your product, Softoxi.com Editor Team decided to award your product with the Top Software Awards:

Softoxi.com's team has also made a VIDEO TUTORIAL showing the installation, the main interface, the main features of CPUInfo, letting our visitors as well as the potential users of your product take a glance at the main qualities of this software before downloading it. This video tutorial is also intended to help beginners understand how to use your product:
CPUInfo Installation Video Tutorial

Moreover, Softoxi.com has tested your software, CPUInfo on 02 08 2011 with 2 of the best antivirus engines available today. We have found it to be clean of any form of malware (viruses, spyware, adware, etc.) - the full reports are available here:

CPUInfo Antivirus Reports

Softoxi.com Editor Team would also like to congratulate you for the high quality standards achieved by your software. We're glad to be able to promote and support such high-quality products in any way we can.

To let your users know about this certification (and therefore about the fact that we consider your product to be a top one), you may display our awards or the conclusion of our review on your website:

Softoxi.com editor team:
"CPUInfo - simple, neat and handy library that determines and displays CPU information in an easy, unified and convenient way."

Softoxi.com Verified Certification:

Many of the other software publishers whose products have been awarded by Softoxi.com have already listed our awards on their website. A link back from your website to your software URL on Softoxi.com would also be very appreciated. It would also help our efforts to promote high quality software such as CPUInfo. Placing our image certificates on your website would also benefit your product as it would inspire trust in its qualities.

More information about your product's certification and the certification award is available on this page:
CPUInfo

Looking forward to hearing from you.

Best Regards,

Rainer - Softoxi.com Editor

At first I thought it was just some spam... you know, an automated script that clones SourceForge pages, in the hope for more hits/ad-revenue.
But then I looked at the actual page: http://www.softoxi.com/cpuinfo.html
There is indeed a video tutorial there, and it doesn't look like it could have been generated by just a script.

I suppose the idea is still the same though: They want me to place these 'awards' on my project page, so they will get more hits... and they are also stealing away direct hits via Google from my original project page, with their clone page.

Nevertheless it is an interesting scheme. I wonder if they will pick up any of my other projects as well.

[p1ranha]

Well, if you are a shareware author you can easily help download sites like those link to your site by submitting your product to the Association of Shareware Professionals.  There is a section which discusses their PAD file - an XML format file that allows sites to very easily download your product's information and list your info.  They even supply a PAD editor to make file creation extremely simple.

It's getting links from the highly ranked shareware download sites that you really want that help drive traffic your way.  Links from them also improve the visibility of your site with organic searches.

It's like todays App Stores, only more old school