Is this project abandoned?

[Ben Graham]

I see a number of "issues", many with helpful patches, but no updates. In addition my own testing reveals that crcutil::Crc32cSSE4::IsSSE42Available() doesn't work in Visual Studio as 

return ((cpu_info[3] & (1 << 20)) != 0);

should be:

return ((cpu_info[2] & (1 << 20)) != 0);
from what I can tell. (Comparing with the Intel provided: 

void get_cpuid_info( CPUIDinfo *Info, const unsigned int leaf, const unsigned int subleaf )
{
	// Stores CPUID return Info in the CPUIDinfo structure.
	// leaf and subleaf used as parameters to the CPUID instruction
	// parameters and registure usage designed to be safe for both Win and Linux
	// when using -use-msasm
	__asm
	{
		mov edx, Info; addr of start of output array
			mov eax, leaf; leaf
			mov ecx, subleaf; subleaf
			push edi
			push ebx
			mov edi, edx; edi has output addr
			cpuid
			mov DWORD PTR[edi], eax
			mov DWORD PTR[edi + 4], ebx
			mov DWORD PTR[edi + 8], ecx
			mov DWORD PTR[edi + 12], edx
			pop ebx
			pop edi
	}
 
	return;
}

#define SSE4_1_FLAG 0x080000
#define SSE4_2_FLAG 0x100000

...
// The code first determines if the processor is an Intel Processor. If it is, then
// feature flags bit 19 (SSE 4.1) and 20 (SSE 4.2) in ECX after CPUID call with EAX = 0x1
// are checked.
// If both bits are 1 (indicating both SSE 4.1 and SSE 4.2 exist) then
// the function returns 1
const int CHECKBITS = SSE4_1_FLAG | SSE4_2_FLAG;
// execute CPUID with eax (leaf) = 1 to get feature bits,
// subleaf doesn't matter so set it to zero
get_cpuid_info( &Info, 0x1, 0x0 );
if ( ( Info.ECX & CHECKBITS ) == CHECKBITS )
{
	rVal = 1;
}
... )



I'm looking for a fast CRC32 implementation, but this one looks to suffer from being a) Too complex to understand if not an expert, and b) Bugs.

Unfortunate really.

[Andrew Kadatch]

Hi Ben,

I'll double-check in about 2-3 weeks (out of country right now). May be a bug indeed.

Thank you,

Andrew

--
You received this message because you are subscribed to the Google Groups "crcutil" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crcutil+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Kadatch]

Yeah, looks like bug indeed -- should be checking cpu_info[2] (contents of ECX). Will fix as soon as I get back. Thanks Ben!

[Ben Graham]

Hi Andrew,

Thank you for looking at this. While you are there, are you aware that the "issues" section of this project has 10 defects raised?

For example, Issue 1.

"Hello,

I have been trying to adapt crcutil as a high-performance, concatenation-capable cksum replacement. However, I notice that the crc32 generating polynomial used in crcutil is the "reverse form" polynomial, 0xEDB88320 (per Wikipedia terminology), not the "normal" form (0x04C11DB7) commonly used. And while the CRC outputs from crcutil match those from BSD "cksum -o 3", when I replace the generating polynomial with 0x04C11DB7 the outputs don't match those from "cksum".

Any advice on what I'm doing wrong?

Thanks,
-ak"

Looks like a potential problem?

[Andrew Kadatch]

No, it's not a problem. It is a mess in the definition of generating polynomial.

When expressed in hex form, least significant bit can correspond to least the

lowest power of 2 -- or the highest.

Unfortunately, both forms are widely used (fortunately, if one "flips" the generating

polynomial we'll still get good CRC which will retain all properties of "true" CRC --

except for compatibility). It is because depending on which architecture we're working

with -- LSB or MSB -- we may have to flip the polynomial.

So one should be extremely careful copying hex representation.

On the good side, typically standards given an example "CRC of this message should

be FOO", which is used to double-check we did it right and didn't flip the polynomial

(or didn't forget to flip it if we're implementing CRC for a platform with different endian

than described/presumed in the standard).

Thank you,

Andrew