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. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
