Repository navigation
Extend Vector64<T>, Vector128<T>, and Vector256<T> to support nint and nuint #52017
Description
Activity
#52021 represents the x86 ISA changes that would be appropriate
#52027 represents the Arm ISA changes that would be appropriate
Hm, maybe I miss something now, but in simple words
nintwill either beintorlong* depending on the bitness of the executing platform. So this would result in eitherVector128<int>orVector128<long>.
Can you give me a use case please? I can't puzzle together anything useful for this right now.* please remember: that's in simple words 😉
We use
nint/nuintin some of our algorithms, such as https://source.dot.net/#System.Private.CoreLib/Utf16Utility.Validation.cs,359.64-bit (
long/ulong) intrinsics tend to not be supported or less efficient on 32-bit machines. While 32-bit (int/uint) intrinsics tend to not fully utilize the CPU on 64-bit machines. Usingnintallows the "natural" data type to be used and can make the overall algorithm more efficient.Got it. Thanks (nice example linked).
Looks good as proposed. A very forward looking question of "what about when nint is bigger than 64 bits?" was asked, and deferred to such a hypothetical date.
namespace System.Runtime.Intrinsics { public static partial class Vector64 { public static Vector64<nint> AsNInt<T>(Vector64<T> value); public static Vector64<nuint> AsNUInt<T>(Vector64<T> value); public static Vector64<nint> Create(nint value); public static Vector64<nuint> Create(nuint value); public static Vector64<nint> CreateScalar(nint value); public static Vector64<nuint> CreateScalar(nuint value); public static Vector64<nint> CreateScalarUnsafe(nint value); public static Vector64<nuint> CreateScalarUnsafe(nuint value); } public static partial class Vector128 { public static Vector128<nint> AsNInt<T>(Vector128<T> value); public static Vector128<nuint> AsNUInt<T>(Vector128<T> value); public static Vector128<nint> Create(nint value); public static Vector128<nuint> Create(nuint value); public static Vector128<nint> Create(Vector64<nint> lower, Vector64<nint> upper); public static Vector128<nuint> Create(Vector64<nuint> lower, Vector64<nuint> upper); public static Vector128<nint> CreateScalar(nint value); public static Vector128<nuint> CreateScalar(nuint value); public static Vector128<nint> CreateScalarUnsafe(nint value); public static Vector128<nuint> CreateScalarUnsafe(nuint value); } public static partial class Vector256 { public static Vector256<nint> AsNInt<T>(Vector256<T> value); public static Vector256<nuint> AsNUInt<T>(Vector256<T> value); public static Vector256<nint> Create(nint value); public static Vector256<nuint> Create(nuint value); public static Vector256<nint> Create(Vector128<nint> lower, Vector128<nint> upper); public static Vector256<nuint> Create(Vector128<nuint> lower, Vector128<nuint> upper); public static Vector256<nint> CreateScalar(nint value); public static Vector256<nuint> CreateScalar(nuint value); public static Vector256<nint> CreateScalarUnsafe(nint value); public static Vector256<nuint> CreateScalarUnsafe(nuint value); } }
You're welcome to assign me 😄
Edit: I was bored and couldn't wait for the issue to be assigned to me.... Therefore I have created a PR
What puzzles me a bit about the proposal is the naming of the methods.
It is usual in the class that the methods are named after the underlying struct. But in this case it was named after the primitive.- public static Vector64<nint> AsNInt<T>(Vector64<T> value); - public static Vector64<nuint> AsNUInt<T>(Vector64<T> value); + public static Vector64<nint> AsIntPtr<T>(Vector64<T> value); + public static Vector64<nuint> AsUIntPtr<T>(Vector64<T> value);
Have you considered this?
It is usual in the class that the methods are named after the underlying struct
NIntmeans it takesnintandIntPtrmeans it takesIntPtrand due to the current language differences, that semantic can be meaningful. It may change in the future, particularly due togeneric math, but as far as API names go; that's the meaning/intent and how other already shipped APIs differentiate.Edit: I was bored and couldn't wait for the issue to be assigned to me.... Therefore I have created a PR
(just posting our Discord conversation for completeness).
I was on vacation and not checking work related GitHub so this got missed. I've actually already done the work here and its in a local branch waiting for other PRs, such as #61649 to get merged before it gets put up.
- ghost locked as resolved and limited conversation to collaborators
on Feb 4, 2022
Proposal
Extend
Vector64<T>,Vector128<T>, andVector256<T>to supportnintandnuintas valid primitive types. This will extend a number of existing generic functions which take aVector<T>to also support taking the new types rather than throwing aPlatformNotSupportedException.Additionally, the following non-generic APIs should be added for parity with the existing surface area: