News for hackers. Stuff that matters.

A comment on A Go implementation of Poly1305 that makes sense. Parent comment

Re:A Go implementation of Poly1305 that makes sense by giovannibajo1 on Wednesday April 03, 2019 @08:36AM (#19562785)
Actually, those functions are intrinsics in the Go compiler on many platforms, so the compiler generates a single ADD / ADC opcode. The source code that you see is a fallback for backends that have not implemented them as intrinsics yet.
[ Parent | on HN ]
Re:A Go implementation of Poly1305 that makes sense by leni536 on Wednesday April 03, 2019 @09:37AM (#19563171)
gcc can optimize generic code for a carry check. To be fair both clang and msvc fails to optimize this specific case.

https://godbolt.org/z/6WXfnL

Edit: OK, I have much worse time generating "adc" instructions, and only gcc sees the opportunity to emit "setc" where appropriate. I see the issue now.

[ Parent | on HN ]
Re:A Go implementation of Poly1305 that makes sense by giovannibajo1 on Wednesday April 03, 2019 @12:12PM (#19564573)
Correct, gcc can generate "setc" but not "adc", AFAIK.
[ Parent | on HN ]
Re:A Go implementation of Poly1305 that makes sense by boomlinde on Wednesday April 03, 2019 @01:36PM (#19565330)
That's true, but I'm specifically addressing the compactness and readability concern.

With respect to efficiency and particularly timing, Go and C seems to be in the same boat here in that depending on your compiler and platform it may either compile to a constant time chain of add/adc equivalent instructions or something sub-optimal and branchy.

[ Parent | on HN ]