undefined | Better HN

0 pointsnomel4y ago0 comments

True, but this is making the assumption that whatever pointer offsets, shifting, and masking that you have in your method, to extract the 9th bit in the 5th word of a 512 bit struct, will result in the same operations as the simple struct access. It very well could be so (certainly for some architectures, most likely not for others), but I don't think all this complication is justified when a struct is available, especially if you're someone writing code for hardware, where these concepts are more known/less scary.

0 comments

3 comments · 1 top-level

ncmncm4y ago· 2 in thread

Compilers do generate instructions specified in functions correctly, inlined or no.

nomelOP4y ago

> Compilers do generate instructions specified in functions correctly, inlined or no.

Well, clearly that's not always the case, as shown in the article, and which is what started this comment chain.

But, I'm not sure how you reached that interpretation. I'm saying that the code that you put into the function will result in some operations, whatever they may be, inline or not. The struct access will result in some operations. The those two sets of operations may be different. Some architectures have specialized instructions for bitfield access. There's a good chance that the complier won't convert the shenanigans in your method to those specialized instructions. Maybe! It requires an understanding of your particular situation. But some people's work exist in a context where this is a reasonable choice, for them.

ncmncm4y ago

If you make bitfield members, and access those in an inline function, and code generation for bitfields tickles a bug, the access being in an inline function won't help.

If you code a shift-and-mask in an inline function, instead, your odds are better, same as if you made a macro for it.

j / k navigate · click thread line to collapse