Peter Cordes wrote:
Anyway, I pushed stuff up to github. I have *not*
turned my changes into a nice patch-series, so all the
mess of development is there. I can re-factor the
commits into a series of clean commits if that's
useful, but you don't use public version-control for
the library so IDK if it would benefit anything
long-term.
I still haven't really looked at float or 256b
vectors yet, but I'd like your comments on
coding-style and how much detail to put in comments
before I start on those.
Thank you for your contributions. I don't have the time to test and commit everything right now, but I will look at it before the next update. You don't have to make nice patch series, as I will review it anyway before I put it into my code. Regarding coding style, I don't like the many helper #defines: they pollute the global name space and they don't improve the readability in my opinion. It is better to have the code in a logical order so that it is easier to find things.
I want to avoid optimizations that are tuned specifically to a particular CPU model, because the market develops so fast that CPU-specific code soon becomes obsolete, and a burden to maintain. |
Test suite for VCL? And how to submit patches new - Peter Cordes - 2016-05-31
Factoring out boilerplate for integer vectors new - Agner - 2016-06-01