I was wondering if someone from the CPU design team could tell me why the upcoming SSE 4.2 instruction CRC32 seems to support only fixed Castagnoli polynomial?
Supporting at least CRC-32-IEEE 802.3 polynomial (0x04C11DB7) would be advantageous (MPEG-2, PNG, V.42, etc).
When we are at it, there is an error in document order #253666-026 on page 258 where Castagnoli polynomial value has one extra "1" at the beginning making it a 36-bit number.
My understanding of the intent for CRC32 implementing CRC32-C is to accelerate software stack in the upper layers of the data protocol traffic. I don't know whether CRC32-C or CRC-IEEE 802.3 apply to broader swaths of data traffic. But it looks like 802.3 standards are more relevant to the physical layer.
Although I'm not privy to the discussions that decided our CRC32, or whether 802.3 were a factor in those discussions. It seems intuitive to me that CPU folks might be more interested in adding CPU capability to accelerate software managing the upper layers of the protocol traffic.
As to the 33-bit polynomial constant for CRC32, it seems there are folks who refer to only the low 32-bits, since the MSB (bit 32) is always 1 andcan be implied. But it is also common for other folks to refer to the full 33 bits of the polynomial constant.
As for additional bit, I haven't seen 33-bit constants defined in code so far, everyone uses 32-bit constants. That is why I asked. I also wrote 36-bit because I think in nibbles :-)
As for not supporting other common polynomials, my guess is that CRC32 tables for different polynomials would use too much real estate inside of a CPU core, but I was hoping to hear official answer (if there is one) as to why that instruction wasn't made to be more flexible?
It also wouldn't hurt if we got MD5 instruction as well.