On Monday, January 30, 2023 at 2:18:29 AM UTC-6, Agner Fog wrote:
> Where can I find documentation on My 66000? I can only find bits and pieces here in comp.arch.
<
If your Google-fu is out of practice: email is:: MitchAlsup@aol.com
<

On Monday, January 30, 2023 at 6:50:03 PM UTC, MitchAlsup wrote:
> On Monday, January 30, 2023 at 2:18:29 AM UTC-6, Agner Fog wrote:
> >
> Hello, Agner, and welcome to comp.arch.

likewise

> You need to remember, The Virtual Vector Method has no vector
> (or SIMD) registers, no trip count or masking register like vector
> machines and SIMD machines. Masking is performed lane by lane
> with predication, vector length is as long as it wants and needs to
> be.

as long as the hardware has resources to autoallocate inflight uOps.
one thing Mitch does not mention is that VVM relies on identifying
Load-Process-Store loops. you cannot Vectorise In-register-only
loops (as best i know) because (as bext i inow) VVM only works
with Load-Process-Store. given that that is a massive percentage
of all generl purpose loops you get a very high bang-per-buck.

> So, My 66000 provides the 373 vector instructions and the 700-odd
> SIMD instructions of RISC-V in exactly 2 instructions.

mmm... a little overstated but pretty much, yes :) the big big
advantage of VVM is you do NOT add one scalar instruction
then also a vector instruction and a tangled morass of
identical SIMD instructions: you just add one Scalar. therefore
anything missing is way easier to add.

> At some point::
> Reduced Instruction Set Computer should have a reduced instruction
> set! My 66000 currently has 62 instructions. In comparison ARM-64
> has 1730-ish instructions.

did you remember to include the 1000s from SVE/2? :)
all gone to hell and not even done well, sigh. non-orthogonal
as they tried to jam into 32bit.

> <
> > Where does it store the decoded loop?
> <
> Different implementations are free to choose this for themselves.
> <
> But, in general, one would expect the instructions to be stored in
> the equivalent of the reservation stations*. These stations have
> become modified to hold onto the instruction (and scalar operands)
> only waiting for the LOOP instruction to signal "another loop", and
> wait for any dynamic operand(s). Think:: multi-fire RS.

another way to think of it is, you have a loop short enough to identify
the start and end, therefore you micro-code back-end SIMD and
multi-issue to the back-end *implicitly*... all without actually needing
any EXPLICIT SIMD instructions.

separate in your mind "SIMD front-end ISA" from "SIMD back-end micro-architecture"
and you will do fine.

> > What about branches?
> <
> One can use predication in vectorized loops but not branches.
> HW assumes that all taken control transfers terminate the loop.
> HW assumes predication provides the if-then-else within the loop.
> <
> > Nested loops?
> <
> There is no nesting of vectorization. outer loops run scalar.

this is possible with SVP64, by storing Vectorisation State on the stack,
but SVP64 is a whole different ballgame and a different paradigm.

l.

On 1/31/2023 7:00 AM, luke.l...@gmail.com wrote:
> On Monday, January 30, 2023 at 6:50:03 PM UTC, MitchAlsup wrote:
>> On Monday, January 30, 2023 at 2:18:29 AM UTC-6, Agner Fog wrote:
>>>
>> Hello, Agner, and welcome to comp.arch.
>
> likewise
>
>> You need to remember, The Virtual Vector Method has no vector
>> (or SIMD) registers, no trip count or masking register like vector
>> machines and SIMD machines. Masking is performed lane by lane
>> with predication, vector length is as long as it wants and needs to
>> be.
>
> as long as the hardware has resources to autoallocate inflight uOps.
> one thing Mitch does not mention is that VVM relies on identifying
> Load-Process-Store loops. you cannot Vectorise In-register-only
> loops (as best i know) because (as bext i inow) VVM only works
> with Load-Process-Store. given that that is a massive percentage
> of all generl purpose loops you get a very high bang-per-buck.
>
>> So, My 66000 provides the 373 vector instructions and the 700-odd
>> SIMD instructions of RISC-V in exactly 2 instructions.
>
> mmm... a little overstated but pretty much, yes :) the big big
> advantage of VVM is you do NOT add one scalar instruction
> then also a vector instruction and a tangled morass of
> identical SIMD instructions: you just add one Scalar. therefore
> anything missing is way easier to add.
>

But, it does mean that the CPU needs to be smarter.
The main advantage of SIMD is that, while it requires more instructions,
it allows for a comparably simpler and dumber CPU.

Main drawback case is if one needs to fake certain SIMD ops via pipelining.

>> At some point::
>> Reduced Instruction Set Computer should have a reduced instruction
>> set! My 66000 currently has 62 instructions. In comparison ARM-64
>> has 1730-ish instructions.
>
> did you remember to include the 1000s from SVE/2? :)
> all gone to hell and not even done well, sigh. non-orthogonal
> as they tried to jam into 32bit.
>

It is a tradeoff.

I can note that SIMD in BJX2 has neither packed byte ops nor saturating ops.

If one mostly only does, say:
Packed Int16
Packed Int32
Packed Binary16
Packed Binary32

And partial:
A few Packed Binary64 ops.

That is comparably fewer ops.
If one skips out convert+op forms (as were present in NEON) this also
reduces the amount of encoding space needed.

Some other cases can be handled via converter ops:
Packed Byte;
Packed RGB555 / RGB444A3;
Packed FP8S/FP8U;
...

This does at least slightly reduce instruction cost.
One other trick (used by SuperH) being to encode parts of the ISA by
twiddling mode bits. Technically sucks though.

>> <
>>> Where does it store the decoded loop?
>> <
>> Different implementations are free to choose this for themselves.
>> <
>> But, in general, one would expect the instructions to be stored in
>> the equivalent of the reservation stations*. These stations have
>> become modified to hold onto the instruction (and scalar operands)
>> only waiting for the LOOP instruction to signal "another loop", and
>> wait for any dynamic operand(s). Think:: multi-fire RS.
>
> another way to think of it is, you have a loop short enough to identify
> the start and end, therefore you micro-code back-end SIMD and
> multi-issue to the back-end *implicitly*... all without actually needing
> any EXPLICIT SIMD instructions.
>
> separate in your mind "SIMD front-end ISA" from "SIMD back-end micro-architecture"
> and you will do fine.
>

Or, one could encode it via prefix encodings, making all of the SIMD ops
64-bit or longer...

Pack4x32 prefix + FADD = Packed 4x Binary32 FADD.

Then one defines which combinations are or are not allowed.

If I were to do this in BJX2, it would probably consist of taking some
instructions which are not allowed in a WEX encoding, and redefining
their use in a WEX encoding as encoding a prefix modifier.

This is possible as I don't really want to burn much more of the 32-bit
encoding space on SIMD ops (as well, most SIMD ops on BJX2 generally
does not allow for operation in bundles, so not being able to encode
them in a bundled form would not be a huge loss).

>>> What about branches?
>> <
>> One can use predication in vectorized loops but not branches.
>> HW assumes that all taken control transfers terminate the loop.
>> HW assumes predication provides the if-then-else within the loop.
>> <
>>> Nested loops?
>> <
>> There is no nesting of vectorization. outer loops run scalar.
>
> this is possible with SVP64, by storing Vectorisation State on the stack,
> but SVP64 is a whole different ballgame and a different paradigm.
>

OK.

> l.