Separated out FP vector ops for cher(iot)-ification of RVV

[vmurali]

Companion to CHERIoT-Platform/cheriot-sail#58

[vmurali]

@rmn30 @nwf , checking if this is the right way to go about it to separate out the floating point processing. The alternative is to separate out the floating point vector instructions upstream, and rebase cheriot's fork after that commit. Let me know which option works better.

[rmn30]

This definitely feels like something that should be upstreamed. What does the RVV spec. say about floating point support? Is it optional? If so the upstream model should support integer only.

I'm keeping an eye on this PR: riscv#506 . It promises to make the model more flexible with regard to included / excluded extensions.

[rmn30]

Another option is to extend the condition on the encdec mapping to include haveF() or haveD()? I think that's what we do in other places.

[vmurali]

They actually have a slew of extensions for embedded profiles (see https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#182-zve-vector-extensions-for-embedded-processors). They also have a V extension that has floating point support depending on whether F and D extensions are available (https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#183-v-vector-extension-for-application-processors). It looks like the V extension is similar to what is implemented in SAIL upstream.

Another option is to keep the floating point code uncommented in cheriot-sail but disable the F and D extensions (and V extension) through the command line.

[vmurali]

Here's the upstream PR FYI: riscv#513