Looks good so far:
it could use float[2] code wherever there is float[3] code
(magnitude2 etc)
any/all should have template overloads to let you specificy exactly
which channels match, and simple hardcoded ones for the common cases
(any1, any2, any3, any4 aka the default 'any')
I have implementations of floor/ceil/round(to-even) that work on
pre-SSE4 hardware for float and doubles I can give out they are fairly
simple, as well as the main transcendentals (pow, exp, log, sin, cos,
tan, asin, acos, atan). sinh and cosh being the only major ones I left out.
I just need a place or address to post or mail the code.
D should be able to handle names and overloading better, though
giving everything unique names was the design choice I made for my
library, primarily to make the code searchable and potentially portable
to C (aside from the heavy use of const references as argument types).
On 2/4/2012 1:57 PM, Manu wrote:
So I've been trying to collate a sensible framework for a standard
cross-platform simd module since Walter added the SIMD stuff.
I'm sure everyone will have a million opinions on this, so I've drawn my
approach up to a point where it properly conveys the intent, and I've
proven the code gen works, and is good. Now I figure I should get
everyone to shoot it down before I commit to the tedious work filling in
all the remaining blanks.
(Note: I've only written code against GDC as yet, since DMD's SSE only
supports x64, and x64 is not supported in Windows)
https://github.com/TurkeyMan/phobos/blob/master/std/simd.d
The code might surprise a lot of people... so I'll give a few words
about the approach.
The key goal here is to provide the lowest level USEFUL set of
functions, all the basic functions that people actually use in their
algorithms, without requiring them to understand the quirks of various
platforms vector hardware.
Different SIMD hardware tends to have very different shuffling,
load/store, component addressing, support for more/less of the primitive
maths operations, etc.
This library, which is the lowest level library I expect programmers
would ever want to use in their apps, should provide that API at the
lowest useful level.
First criticism I expect is for many to insist on a class-style vector
library, which I personally think has no place as a low level, portable API.
Everyone has a different idea of what the perfect vector lib should look
like, and it tends to change significantly with respect to its application.
I feel this flat API is easier to implement, maintain, and understand,
and I expect the most common use of this lib will be in the back end of
peoples own vector/matrix/linear algebra libs that suit their apps.
My key concern is with my function names... should I be worried about
name collisions in such a low level lib? I already shadow a lot of
standard float functions...
I prefer them abbreviated in this (fairly standard) way, keeps lines of
code short and compact. It should be particularly familiar to anyone who
has written shaders and such.
Opinions? Shall I continue as planned?
