CRC32 code
Posted: Sun Apr 16, 2017 6:04 pm
Been dabbling lately in the TunerStudio interface and, with the NewSerial protocol, CRC32 naturally came up. The MS2 implementation in crc32.s was pretty obviously based on output from gcc. I thought I'd have a go at something a bit more hand-crafted.
This has pulled a reasonable performance improvement (times in CPU cycles):
I don't know what the largest thing encoded is going to be, but the latest OutputChannels is 212 bytes, so 208 would be close to that. At 24MHz that has gone from 680us to 470us. Whether it'll even show up in looptime, I'm not sure --- I've just had a quick look at looptime and I see it averages-in values, so I guess it might have a small effect. Mind you, I think it'd make more sense for looptime to be the MAX value encountered since last send, and reset it to zero after each send. That way you'll see the worst case.
To me CRC32 seems to be huge overkill and an 8 or 16-bit hash would have done the job much more cheaply. Perhaps this was needed anyway for CAN?
On the whole, this isn't terribly exciting. It'll only have an effect at all when something's polling RS-232 or CAN. It's just that I felt like writing a bit of assembly language code and this seemed a good candidate. I even wrote it in lower case since you guys aren't so keen on "traditional" style.
Finally, a couple of notes on the code. All calls to this function pass a first argument of 0L, which seems a bit wasteful. I've written the function assuming this value to be zero. I suggest all callers should get rid of the first argument. I've only tested it in the CodeWarrior simulator (hence the cycle counts). It gets the right answers and ends with an RTC instruction; I believe it's plug-compatible with the original, but obviously it needs to be tested in a MS2. It's in the public domain now, so do with it as you wish.
Have fun,
Rob.
This has pulled a reasonable performance improvement (times in CPU cycles):
Code: Select all
n new old
6 394 568
208 11272 16321
1024 55336 79969
To me CRC32 seems to be huge overkill and an 8 or 16-bit hash would have done the job much more cheaply. Perhaps this was needed anyway for CAN?
On the whole, this isn't terribly exciting. It'll only have an effect at all when something's polling RS-232 or CAN. It's just that I felt like writing a bit of assembly language code and this seemed a good candidate. I even wrote it in lower case since you guys aren't so keen on "traditional" style.
Finally, a couple of notes on the code. All calls to this function pass a first argument of 0L, which seems a bit wasteful. I've written the function assuming this value to be zero. I suggest all callers should get rid of the first argument. I've only tested it in the CodeWarrior simulator (hence the cycle counts). It gets the right answers and ends with an RTC instruction; I believe it's plug-compatible with the original, but obviously it needs to be tested in a MS2. It's in the public domain now, so do with it as you wish.
Have fun,
Rob.