[libre-riscv-dev] uniform instruction format

[Jacob Lifshay]

One way to handle svlen is to have vstart count to VL*SVLEN instead of just
to VL. That could simplify the CSR state somewhat. Though having a separate
2-bit field in vstart may be better after all -- I'd suggest having at
least 16 bits of space in vstart for the vl subfield to allow later
expansion.

One idea for expanding VL past XLEN is to use N sequential registers to
store N*XLEN predicate bits, similar to how a 4x32-bit subvector takes 2
64-bit registers.

Alternatively, we could use a N x u8 vector to store N predicate bits, as
if it was `bool pred[N];` -- the lsb of each u8 would be used as the value
and when storing to the u8 vector each element would be 1 (true) or 0
(false).


On Sat, Jun 22, 2019, 23:10 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> Darn, nearly missed it, an extremely important thing: to support svlen
> (SUBVL) the index (current value of the for loop) *must* be part of the
> context.
> ie part of the STATE CSR.
>
> Otherwise we are forced to actually make the svlen a full SIMD concept,
> forcing implementors to create ALUs that will do 1, 2, 3 or 4 operations in
> a group, per cycle.
>
> Or, force them to treat the group as atomic in some other fashion, such as
> preventing and prohibiting exceptions and so on.
>
> An index allows implementors to break up the svlen loop into its individual
> elements.
>
> Only caught this after writing out the pseudocode for svlen.
>
> Whew.
>
>
>
> --
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>