Previously the detection only tested this AMD CPUs and the table check was
only present in recog_amd.c
Thanks to Andrew Roberts for reporting this issue!
Reorganize the detection for Intel Atom CPUs
- no longer make the distinction between single- and dualcore CPUs.
- correctly handle all Pineview and Cedarview CPUs.
- Atom Dual-core (Diamondville) is renamed to just Atom (Diamondville)
- The test with Atom D425 is named "Pineview", while the one with
Atom D525 was incorrectly named "Cedarview". Moving the latter to
atom-pineview-2.test and fixing its codename.
Namely, printing a uint64_t with printf(...%llu...) is considered bad
practice; you need to use the format specifier PRIu64, defined in
inttypes.h. Apparently, it's not safe to assume that
uint64_t == unsigned long long.
However, I don't like this kind of formatting uglyness.
The td variable on my machine is ~30k - and conceivably can't go
above 1M. Moreover, this printf is only for detailed debug purposes.
So it's safe to cast the var to int and print it with %d.
Automake >= 1.12 seems to require AM_PROG_AR to be happy with our
configure.ac. However, this macro is not defined on < 1.12, thus
the ifdef.
Confirmed that the project bootstraps without warnings on both
Fedora 14 and Ubuntu 13.10.
Remove the line with the build date of the library from the
raw serialized file format. It doesn't help anything and it
bothers the openSUSE packaging guys. Having the current
date into a binary triggers a warning:
"Current date containing causes unnecessary package
republishing."
Confirmed that "strings libcpuid.a | grep 2014" no longer
contains the current date.
Also, the sse-width guesswork seems to handle this (wrong) Griffin ext_family
explicitly, so fix it there as well.
Seems that members of ext_family 20 (AMD Fusion based APUs) also are 64-bit,
but they have the authoritative sse width detection bit, so we don't need
to handle them explicitly here.
It seems that our SSE-based speed test is 1 IPC (instructions per clock)
on all current CPUs, and 1.4 IPC on the Bulldozer, which leads to its
result being 40% too high. Correct that in the function.
Instead of one big pile of tests in tests_stash.txt, keep each CPU
example raw data/parsed data in a file, ordered in a tree by
manufacturer and microarchitecture. The 64 .test files have been
extracted from tests_stash.txt. The add_test script is changed to
create_test and it doesn't append to test_stash.txt, instead it
spits out data to be saved in a .test file.
run_tests.py is not refactored yet, to be done in a subsequent commit.
- Move detection of constant_tsc to common; it is spec'd in Intel docs
- Fix broken interpretation of EAX in leaf 80000000h: it shows max
800000xx-value, not max xx-value. This causes, for example, to seek
for extended features on Pentium II, where the extended leafs aren't
supported by the CPU at all.
This is only in common feature detection. AMD detection is fine.
- Add detection of a few new features in AMD leaf 80000007h: cbp (core
performance boost), aperfmperf (APERF/MPERF MSRs supported),
pfi (processor feedback interface) and pa (processor accumulator).
"make test" is broken right now, to be fixed in a subsequent commit.
Previously, 0.2.1 was mentioned in libcpuid.h, but this was not,
actually, in effect; it wasn't mentioned in autoconf and Visual Studio
project files. Also, cpuid_lib_version() still returned "0.2.0".
The .am files contained obsolete data (to include libcpuid.sln/libcpuid.vcproj
in a dist). These files are now in libcpuid_vc71.* and libcpuid_vc9.* flavours,
thus this change. "make dist" now works.
This adds support for x2apic detection. This is not a direct merge, since
- the feature is spelled as 'x2apic' instead of 'x2APIC', for consistency with other flags;
- tests are added
- the id of the feature is moved to the end of the cpu_feature_t enum, for binary
compatibility.
