[vector] mulAll for byte and short

[Paul Sandoz]

Thanks John, that’s a useful way to think about the problem. For many cases S == T, so an additional type variable could be hidden in the above class hierarchy. I think we could do it with a combination of species and limited specialized vector types for supported combinations of S and T so the primitive form of S is exposed in signatures of those types.

Paul.

> On May 18, 2018, at 12:45 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> On May 18, 2018, at 12:09 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> 
>> Hi,
>> 
>> I cannot recall if this was discussed before and i did not find anything in prior emails. 
>> 
>> Out of all the reduction operations mulAll is an outlier and does not support byte and short? is than an oversight or deliberate? I suspect the latter but just wanted to double check.
> 
> A recurring theme is what to do about subrange types where overflow is more
> likely because of the narrower range.  Applies to almost every operation, except
> and/or/xor/not/neg.  Even add can overflow.
> 
> Here's a model that might let us make a little more progress with such operations,
> if not now then later.
> 
> A vector type is a tuple of (Len, T, S :> T, Store: S->T).
> 
> 1. a lane type T has a size and format (signed, unsigned, float, maybe also "just raw bits")
> 2. a lane type also has an associated scalar format S, which may be larger
> 3. arithmetic on lanes is defined as if performed in the associated scalar format
> 4. scalar result values are stored back into lanes using a type-specific Store function
> 5. when a vector returns an accumulated cross-lane result, it returns the scalar type S
> 
> If a result value S is not representable in the lane type T, the store function usually
> performs truncation, as in Java.  However, special vector types may instead perform
> saturation or throw overflow errors.
> 
> Adding this extra type S would allow us to model Java's rules for questionable operations
> like logical shift on bytes and shorts.  Java promotes those guys to int (JLS 5.6.1) ,
> so if T is byte then S is int.
> 
> Such a two-type framework might also help when dealing with small types which do not
> correspond to Java primitives; I'm thinking of short float here, where T is 16 bits and S is
> Java float.  Of course, if the CPU performs native 16-bit float arithmetic, the framework
> wouldn't fully account for the numeric results produced, so it's not perfect.  But maybe
> it helps.
> 
> Maybe we can hide the extra features (S, Store) in the species, or even the shape.
> 
> — John