Reported via http://libcpuid.sourceforge.net/bugreport.php
The test in particular has no brand string, which was causing the
misdetection (as is the case with a lot of other models, libcpuid
relies on accurate brand string being programmed by the BIOS in
order to do the detection).
The actual CPU was a Pentium-III based Celeron (SL54Q), but it
was detected as "Pentium III (Coppermine)".
A bit of historical trivia: for the related Tualatin models, if
the BIOS doesn't enter a brand string, there might be NO WAY to
tell a regular P-3 and a P-3 Celeron apart: P-3s have variants
with 256KiB and 512KiB L2 cache, while the Celerons are 256 KiB, so
a 256KiB regular P3 is no different than its corresponding Celeron.
Only the FSB is different, but there's no way to detect this via
CPUID.
For the Coppermines its an easier case: Celerons are always 128KiB,
and Pentia are 256KiB, so I've added this distinction in the tables.
Add support for detecting Coffee Lake i[357]s. Test included.
Thanks to @X0rg for reporting and to @exdeus for the raw cpu data.
The detection here relies on Kaby and Coffee lakes having different
number of cores for the equivalent brand:
i3: 2 cores in Kaby, 4 in Coffee
i5 and i7: 4 cores in Kaby, 6 in Coffee.
It is very simple detection - if the brand string contains " APU ",
the _APU_ bit in amd_code_and_bits_t::bits is set.
Simplify one other line as well.
There were a lot of instances where there was additional code
written to detect certain features from the brand string
(e.g., does it have "Core (TM)"? if it has, does it have "i3"?).
It makes sense to only write code for detecting these features
in isolation, preventing the exponential blowup of possible
intel_code_t values (e.g. previously there were enum values
for CORE_{,IVY,HASWELL,BROADWELL,SKYLAKE}{,M}{3,5,7} - almost
20 separate enums items; these can now be expressed with the
respective bits (CORE_, _I_, _M_, _3, _5 and _7).
The change in matchtables is the addition of an extra field
after brand_code: it is called model_bits. The bits for each
vendor is defined in the beginning of recog_<<vendor>>.c
This is the first part of the overhaul, which handles the bits
detection and proper matchtables for Intel. Refactoring of
AMD detection code coming next...
