[Libre-soc-dev] results of phone call about simple-v prefix

[Jacob Lifshay]

Luke, Cole, and I had a phone call to explain simple-v prefix to cole as
well as resolve the disagreements:

we decided that using a bit in the page tables may not be the best idea due
to needing to modify all of llvm, gcc, the elf spec, the dynamic linker,
binutils, etc. so we're most likely falling back to a mode switch bit in a
SPR.

we decided that including bits in SVP for setting vector length was no
longer necessary since things like webassembly or simd.js that require
fixed-length 128-bit simd would just use vsx/altivec instructions like
usual. most other applications for SVP don't need to change vector length
that often -- GPU shaders would set it at the beginning of the shader and
not change it for the rest of the shader. Video stuff would probably not
need to constantly change VL as well, since the most common operations
would work on large blocks (8x8 or bigger) leaving plenty of time to change
VL since the processor is multi-issue. We do need to double check with
those working on Video.

we decided that it's worthwhile to spend some time trying to fit all of
SVP64 into primary opcode 1 sharing it with Power v3.1 instructions. If we
fail, we only wasted a week or so and can fall back to the (less desirable
for me) plan of using several primary opcodes to make enough space for the
old encodings designed for RISC-V. likewise for SVP48/SVP32.

we mostly resolved the issue of encodings for primary opcodes 0, 1, and 5
potentially being decoded as valid but unintended instructions on old power
processors, we will need to double check that they trap on old processors.

I probably forgot a bunch of other things, I'm assuming luke & cole will
send to the mailing list the ones they think are important and/or I
misremembered.

Jacob