Consider using bit fields in the CPUINFO structure instead of bytes for every feature. Possibly per sections (e.g. ACPI) and per extension group (e.g. SSE grouping SSE, SSE2, etc., and AVX512 and all its stuff).
We wouldn't really lose a whole lot in speed. At worse it's an inlined function/template that performs a single AND (&) operation.
This would be best implemented using uint (u32) fields. The VendorID could also be included in CPUINFO. The memset could be moved in the fetchInfo function. And CHECK could have an extra or two parameters.
TODO:
[x] Make branch feature-bitfields
[x] Move VendorID to CPUINFO
[x] Move memset operation in fetchInfo
[x] Populate CPUINFO with new fields
[ ] Replace CHECK with something that checks register bit + sets bit on CPUINFO member (with enum value) so: (MEMBER, MEMBERBIT, REGISTER, FEATUREBIT)
if (REGISTER & FEATUREBIT)
STRUCTURE.MEMBER |= MEMBERBIT;
[x] Make new member enum feature values (e.g. SSE.SSE2 or EXT_SSE2 or FEATURE_SSE_SSE2)
[x] Put new (REG & FEATURE) => SECTION |= FEATURE
[ ] Run new CHECK replacement function
FUNCTION(MEMBER, FEATUREBIT, FEATURESTRING) => print if true
dd86k
commented
4 years ago
Consider using bit fields in the CPUINFO structure instead of bytes for every feature. Possibly per sections (e.g. ACPI) and per extension group (e.g. SSE grouping SSE, SSE2, etc., and AVX512 and all its stuff).
This would benefit in a few areas:
memsetarea is smaller to deal withWe wouldn't really lose a whole lot in speed. At worse it's an inlined function/template that performs a single AND (&) operation.
This would be best implemented using uint (u32) fields. The
VendorIDcould also be included in CPUINFO. The memset could be moved in thefetchInfofunction. And CHECK could have an extra or two parameters.TODO:
feature-bitfieldsReplace CHECK with something that checks register bit + sets bit on CPUINFO member (with enum value) so: (MEMBER, MEMBERBIT, REGISTER, FEATUREBIT)