Re: Crc32

[valerij zaporogeci <vlrzprgts@gmail.com>]

Please read this, don't discard hastily, it might be intesting for the project.
I have a suggestion about the implementation of Crc32 found in this place:
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/RuntimeDxe/Crc32.c

Figuring out why proper mathematical crc calculation differs from
results returned by this function, I found it's because the function
reverts bits in bytes. It's all clear, this is a need rooting from
some hardware protocol requirements and specifics (ethernet?), where
it was needed and here it is repeated as it became a de facto
standard.
But looking at the implementation, I found that it is possible to get
THE SAME results with much less processing. Namely, instead of
reverting every byte in the sequnece (moreover, please note, that the
implementation in fact casts every byte to UINT32 and only then
reverts it - yet 4 times more of a wasting job), so, instead of
reverting every byte of the entire message (which might be of any
size), we might statically revert bits ONLY in the Polynomial
representation itself. And that's all! It's absolutely identical
mathematically. It returns identical results on every input. But it is
a significant performance improvement. The interface and semantics
would not change, they remain the same for any caller. Internal
ReverseBits() function is not needed any more and doesn't get called
anywhere. The implementation remains the same table driven, but the
table initializes now MUCH more faster (without reverting).
If you have interest in this suggestion, I have prepared (and tested)
the changed file in question, and might send it if there would be
interest.
Thank you.
PS. It is NOT changing a polynomial. It's improvement of the internal
implementation which takes into account (strange) treatment of bit
ordering of this particular case.