x86 _rdtsc has wrong return type

[GabrielMajeri]

This issue is related to the recently stabilised x86 intrinsic function _rdtsc

The issue is that the function is defined to return a signed i64. This is in accordance with Intel's documentation. However, that is not how most people define it, including C/C++ compilers.

This is how GCC defines it:

extern __inline unsigned long long // < note the return type
__attribute__((__gnu_inline__, __always_inline__, __artificial__))
__rdtsc (void)
{
  return __builtin_ia32_rdtsc ();
}

This Clang example proves it also defines it as unsigned long long.

Now, I'm confused. Since the timestamp counter is a monotonically increasing timer, it wouldn't make sense to return negative values. In fact, I think it is allowed to return values with the most significant bit set (which would make the returned value negative, unless transmuted). Is the mismatch intended?

[gnzlbg]

This is in accordance with Intel's documentation.

core::arch implements the Intel's spec as close as possible. Bugs in the spec should be reported to Intel, but the spec uses signed integers in many places in which it could use unsigned ones. Why? No idea.

FYI the main reason we decided to implement the spec 1:1 is that we don't have the manpower to design a new API for each of the tens of thousand intrinsics that belong in core::arch.

---

FWIW you can write a thin wrapper that transmutes i64 into an u64 if you prefer that API in stable Rust (its a no-op). Also, clang probably just did the same thing as GCC to be compatible with it.

[GabrielMajeri]

@gnzlbg I have raised an issue with Intel about this intrinsics. Hopefully they'll reply and fix their spec.

[gnzlbg]

I have raised an issue with Intel about this intrinsics. Hopefully they'll reply and fix their spec.

So I don't hold my hopes up here because this would be a breaking change, so I'd suspect that nothing will happen. However, Intel and other vendors do send errata and make breaking changes every now and then, and I'm interested in seeing how we would deal with that.

@GabrielMajeri in the mean time, this particular function is defined in the Intel spect as just reading the content of a register, so it doesn't really matter whether the return value is a signed or unsigned integer (or an [u8; 8] or whatever) as long as it is 64-bit wide. Its "the user"s job to interpret those bits as appropriate. I don't know what the value of the register "means" when the sign bit is set, but I'd expect it will just be an unsigned integer.

I have a crate in progress to strongly type all intel intrinsics here and expose them using a safe API when possible: https://github.com/gnzlbg/typed_arch I'll take a PR that implemented the rdtsc intrinsics with a "better" and safe API.

---

EDIT: do you have a link to the Intel issue / bug report / tracking id?

[GabrielMajeri]

@gnzlbg Well I submitted a comment to this forum thread which is where the Intrinsics guide told me to post issues to. The comment is still waiting for moderator approval, and then I'll wait for a reply from Intel staff.
Edit: the comment is approved now, we just need to wait

To me it just looks like an issue with their documentation, considering they did mess up the types in their intrinsics guide before.

[gnzlbg]

@GabrielMajeri is there an acknowledgment of the bug or where you contacted about it ? Otherwise it might be worth it to start a new thread there just about that.

[GabrielMajeri]

I've tried submitting another message, although it seems the intrinsics guide is not exactly a priority. I wouldn't consider it to be an official specification in any way, just a helpful resource for developers who are looking for documentation on how to use the intrinsics.

[gnzlbg]

Sadly, there does not appear to be a real "specification" of Intel compiler C intrinsics beyond the intrinsics guide. I'm going to merge the PR, and try to update stdsimd upstream doing a crater run with it. Maybe we can fix it.