Re: Short Vectors Versus Long Vectors

Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

Scott Lurndal wrote:
>

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

Adding the typical kind of vector-processing instructions to an instruction set inevitably leads to a combinatorial explosion in the number of opcodes.

>

Why is that a problem that needs solving?

>
When your OpCode encoding space runs out of bits in the instruction.

And has that been a real problem yet?   Pretty much every
instruction set can be easily extended (viz. 8086),
particularly with variable length encodings, nothing prevents
one from adding a special 32-bit encoding that extends the
instruction to 64-bits even in a fixed size encoding scheme.

I suspect as long as RISC-V maintains its 32-bit only ISA,
that REIC-V will hit that wall first.

>

This kind of thing makes a mockery of the R in RISC.

>

So what?

>
Design + verification cost, time to market, Size of test vector set,
and Compiler complexity.

As contrasted with usability.    ARM doesn't add features just
for the sake of adding features, nor does Intel.

Are you sure ?? Take SSE-512 (or whatever Intel calls it) !!
When I was at AMD (99-06) every 6 months or so, we (AMD) got Intel's
latest instructions additions, and they gout ours. Most of these
additions end up at the 0.01% level of the dynamic instructions
executed (over a wide range of programs (more than 40,000 traces)),
and all cores had to have all of the instructions.
Is this a burden on Intel:: not so much since they already have
extensive (exhaustive??) tests and implementation libraries....
Is this a burden on AMD:: yes, absolutely; the smaller design staff,
they can afford based on their revenue stream, increases the burden
significantly.