Implement additional bit twiddling intrinsics about dora HOT 6 CLOSED

Further thoughts:

• Would it make sense to also add functions for the (trivial) inverse operations ("Count of Number of Bits Set to 0", "Number of Leading One Bits", "Number of Trailing One Bits")?
• What's a good, consistent naming scheme for these functions? Ideas:
  • countZeroes/countOnes, countLeadingZeroes/countLeadingOnes, countTrailingZeroes/countTrailingOnes
  • countZeroBits/countOneBits, countLeadingZeroBits/countLeadingOneBits, countTrailingZeroBits/countTrailingOneBits
  • countZeroes/countOnes, countZeroesLeading/countOnesLeading, countZeroesTrailing/countOnesTrailing
  • ...

from dora.

Hardware requirements:

• POPCNT requires at least Nehalem/K10
• LZCNT requires at least Haswell/K10.
• TZCNT requires at least Haswell/Piledriver.

The newest instruction is therefore at least 7-8 years old – I'd think it would be reasonable to implement the bit ops without a fallback, and instead check on VM startup that the CPU is recent enough ...

from dora.

Personally I would simply assume that the CPU is recent enough and not implement a fallback or startup check at all ;)

But obviously feel free to implement whatever feels right to you.

from dora.

Makes sense! Maybe we should have code to deal with unsupported instructions in general though, because currently that crashes the runtime with

error: trap not detected (signal 4, addr 0x7f114d840fe7).

Took me a while to figure out why the code was fine on my workstation, but fell apart on my old notebook. :-)

from dora.

Weird, the crash doesn't seem to be related to an unsupported instruction; I get the same on a machine that supports popcount.

from dora.

Let's close this and open individual issues for operations that may be worthwhile to implement.

from dora.