Vector API Latest Draft Spec

[Paul Sandoz]

> On 14 Jul 2017, at 12:51, Graves, Ian L <ian.l.graves at intel.com> wrote:
> 
>> As an experiment i just pushed a template mechanism that can generate the
>> vector code. I resisted the temptation to do some major refactoring, so the
>> template generator tries to keep things as close as possible to the original
>> code (with slight differences when operating on the FP domain when doing
>> bitwise operations). Conservatively i have not yet replaced the existing
>> implementations.
> 
> Awesome!  There's a lot of boilerplate to factor out.
> 
>> 1) There is no need to have entirely separate implementations for every bit
>> size of an element, there can be a common parent class for most things.
>> 
>> 2) We can use a simple forEach abstraction to avoid the loop repetition.
> 
> I agree.  Most of this code is copy/pasted.  The loops need to go, but I wasn't sure what to replace them with.
> 
> 
> 
>> If there are no objections i’ll keep plugging away at this.
> 
> Please do!
> 

Done. It’s a little bit more manageable, plus it’s easier to see how this could be generated dynamically [*] (what John refers to as binding).

A further step is to abstract out the direct array access, then perhaps we could switching to LongX holder types, and this implementation might become the basis of something that is intrinsified?

Paul.

[*] many method implementations could be generated on demand with indy using a shared BSM where the implementation is derived from the method name and arguments. It would be nice to enhance the class file format to declare a method as a BSM stub i.e. no need to declare a method body.