Sujet : Re: What integer C type to use
De : already5chosen (at) *nospam* yahoo.com (Michael S)
Groupes : comp.archDate : 15. Mar 2024, 13:01:09
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20240315140109.00006006@yahoo.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
User-Agent : Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
On Thu, 14 Mar 2024 23:56:04 -0400
"Paul A. Clayton" <
paaronclayton@gmail.com> wrote:
On 3/13/24 3:24 PM, MitchAlsup1 wrote:
Stefan Monnier wrote:
[snip]
So, short vectors have a fairly free hand at shuffling data across
their vector (e.g. bitmatrix transpose), and they can be
implemented/scheduled/dispatched just like any other instruction,
but the vector length tends to be severely limited and exposed all
over the place.
Consuming OpCode space like nobody's business.
Is that necessarily the case? Excluding the shuffle operations, I
think only loads and stores would need to have length specifiers.
Shuffle operations become much more expensive with larger
'vectors', so providing the same granularity of shuffle for larger
vectors seems questionable. (With scatter/gather, permute/shuffle
may be less useful anyway.)
<snip>
Am I missing something when I assume that lane-based (SIMD)
operations do not need size information in the instruction? The
extra metadata is not free (perhaps especially as that controls
execution at least for efficiency), but if opcode explosion is so
undesirable using metadata might be preferred.
I would guess that Mitch operates under assumption that we are still
talking about ISA that is very similar to CRAY Y-MP.
I.e. non-load-store, but more like AVX512, where one of the source
operands could be in memory.
That is, I had never seen CRAY Y-MP ISA docs, but would imagine that it
was like that.