[Libre-soc-dev] new svp64 page

[Jacob Lifshay]

On Thu, Dec 10, 2020, 12:54 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> dest elwidth overrides has secondary purposes such as providing
> multiply widening.
>

Wouldn't mul-high provide nearly all of what we need?

>
> one of the "disadvantages" of the RISC approach where pre/post
> processing is controlled uniformly by N bits is: some combinations
> just do not make sense.
>
> for example: saturation bits on logical ops are totally meaningless.
>
used to express average, as mentioned below

likewise, elwidth overrides except to truncate or zero-extend.
>
you still need elwidth overrides to get the right element size otherwise
instructions might process too-few/too-many registers causing issues.

There might also be microarchitectural reasons to express the elwidth and
subvector length, even though they appear redundant for logical ops, since
some future microarchitecture could have a separate 16/8 bit datapath from
32/64 or something like that, and that would allow the compiler to specify
which datapath to use.

> For implementing average,
> > we could encode that by repurposing xor (or some other bitwise op) with
> > saturation to instead mean averaging add.
>
> ah now in light of the above that makes sense.  reuse opcode space
> rather than allocate new ones.
>
> except... i was thinking in this particular case, actually adding avg
> *to* OpenPOWER v3.N actually has a reasonable justification: reduction
> of the SIMD post-cleanup code size.
>

Except scalar avg wouldn't be that common and SV prefix can be totally
scalar.

>
> it puzzles me that there's all this wonderful powerful SIMD ops yet
> the scalar ops, absolutely crucial to do cleanup of non-aligned
> multiples of the SIMD size, are left without corresponding ops!
>

VSX has scalar avg -- after all, that's what the S in VSX stands for:
Scalar.

Jacob