https://hg.paper.us.eu.org/vec/ en-us src/impl/generic.c revision history https://hg.paper.us.eu.org/vec/log/8b5e0974fd41/src/impl/generic.c Paper <paper@tflc.us> Fri, 25 Apr 2025 17:40:46 -0400 https://hg.paper.us.eu.org/vec/log/bf6ad516f1e6/src/impl/generic.c Paper <paper@tflc.us> Fri, 25 Apr 2025 17:40:33 -0400 https://hg.paper.us.eu.org/vec/log/c6c99ab1088a/src/impl/generic.c
agh, this time I added a few more implementations (and generally
made the code just a little faster...)]]> Paper <paper@tflc.us> Thu, 24 Apr 2025 00:54:02 -0400 https://hg.paper.us.eu.org/vec/log/92156fe32755/src/impl/generic.c
the signed average function is wrong; it needs to round up the number
when only one of them is odd, but that doesn't necessarily seem to be
true because altivec is weird, and that's what we need to emulate the
quirks for. ugh.

also the altivec backend uses the generic functions instead of fallbacks
because it does indeed use the exact same memory structure as the generic
implementation...]]> Paper <paper@tflc.us> Sun, 24 Nov 2024 11:15:59 +0000 https://hg.paper.us.eu.org/vec/log/e26874655738/src/impl/generic.c
I keep finding things that are broken...

The problem NOW was that vec would unintentionally build some
functions with extended instruction sets, which is Bad and would
mean that for all intents and purposes the CPU detection was
completely broken.

Now vec is no longer header only either. Boohoo. However this gives
a lot more flexibility to vec since we no longer want or need to
care about C++ crap.

The NEON and Altivec implementations have not been updated which
means they won't compile hence why they're commented out in the
cmake build file.]]> Paper <paper@tflc.us> Sun, 24 Nov 2024 02:52:40 -0500