Initial Steps Outline

[Lokathor]

We have the following initial things to do, in approximately this order:

• Get the CI set up with tests running on as many targets/arches as we can muster. Besides just i686 and x86_64 we also need:
  • i586, because it doesn't have sse enabled, and that makes trouble, so we wanna spot it right away.
  • something with avx-512 support. could be emulated if we have to. The tests don't have to execute super fast as long as the results are correct.
  • An ARM target (v7 + neon), and an Aarch64 target (v8), because even though they're both "neon" there's some differences some of the time, and again we wanna be aware of that up front.
  • Every other weird target we can get the CI set for. Our claim is to be portable after all. stdarch is probably a good guide here because they're already testing on all sorts of stuff.
• Get all our 64-bit, 128-bit, 256-bit, and 512-bit types into the crate.
  • Nothing too fancy, we just declare each struct with all the attributes it needs to compile with the right layout and all that.
  • I believe that the plan was to do this non-generically, so we'll have a big pile of types gettin' written out in this step.
  • Personally I'd like to have one type per module, with the modules as crate-private and then the content of each module re-exported from the crate root. This keeps things easy to work with on a day to day basis but also keeps the public API nice and flat. Remember that in actual usage anything in this crate is going to have core::simd or std::simd in front of it already, so we should keep a shallow public API as much as we can.
• Get type change methods for every type.
  • From/Into with appropriate arrays (this can likely be a transmute internally)
  • From a single element ("splat"), and probably a bespoke splat method too, for API discoverability.
  • A plain old new method of course.
  • Methods for safe transmuting to/from the native SIMD format (when there is one).
• Get formatting impls for every type.
  • This isn't just Debug, but also Binary, Octal, UpperHex, LowerHex, all that. Arguably even Display should be added.
  • It might seem silly to make this a whole point of its own, but trust me you're gonna want the flexibility when doing those unit tests.
  • Most of this can be done via macro_rules, you just change the SIMD type into an array, and then format the slice.
• Get PartialEq for every type.
  • This does not give a SIMD output just because we're comparing SIMD types for equality, you just get a normal bool, so you actually don't want it for SIMD processing, but it is required for assert! to work, so again we need this for working on tests.

And at that point, we'll be in a position to actually begin writing the "useful" parts of the crate.

[calebzulawski]

I can take a stab at getting some of the initial types and methods out today/tomorrow (unless of course you were planning on it!)

[Lokathor]

i think the CI setup was planned for "sometime this week", but i suppose that we can get a bit started before that and just fix it up later if things show an error.

[KodrAus]

Ah yes I have CI on my list for tomorrow. Hopefully we can get it bootstrapped that day, but CI has a habit of getting drawn out.

[calebzulawski]

I just opened #2 which adds the initial types and some of those conversion traits.

[Lokathor]

Update: With #2 merged, we have the basic setup in terms of code. We just need some CI to check our future PRs against and we'll be on the way to a quality crate.

[Lokathor]

WE'RE INITIAL