Odpověď na názor

Nemáte zač.
Dnešní definice znamená spíš tohle:
- CISC = Complicated decoding
- RISC = Rapid decoding

Všechno ostatní o komplexní x86 jsou kecy od lidí co tomu vůbec nerozumí.

Máte 100% pravdu s tím zjišťováním délky a problémům s tím spojenými. Logicky i ta RVV když nastane contex-switch a OS to uprostřed výpočtu hodí na Little jádro co má jinou délku registru, tak to zhavaruje.

Dá se to ošetřit? Určitě, CPU si může nějakou instrukcí vynutit zákaz context-sw, nebo naopak detekovat CS přes přerušení, nebo speciální registr kam se dá adresa instrukce když nastane změna délky registru. Tam dáš adresu se subrutinou která to ten CS ošetří.

Ale není to ideální, je to porušení abstraktnosti mezi ISA a HW ala VLIW Itanium. ISA by měla být nezávislá na HW, jinak se právě dostává do takových sraček jako 6 verzí SSE, 3 verze AVX a 15 verzí AVX512.

Správně by to ISA měla řešit: obyč skalár instrukce + multiplikátor kolikrát se má vykonat (ta instrukce pro multiplikace by si pro další iterace automaticky načítala další hodnotu z pole hodnot/array v C++, prostě vektor). Tím SW vůbec nemusí zjišťovat šířku vnitřních SIMD jednotek, protože to nepotřebuje, protože to je čistě starost HW. Zároveň při 16-bit hodnotě multiplikace (což se do 32-bit šířky ARM instrukce vejde) to umožňuje vektory dlouhé až 65 tisíc hodnot. To by byla paráda (ta RVV se tomu snaží alespoň přiblížit). Ale hlavně to umoňuje využít efektivně HW, protože ten vektor nerozsekává na menší, ale naopak plní FPU jednotky od jedné do maxima co má CPU vnitřně. Takže je SW je kompatibilní i s CPU v mikro-kontroléru který má jen jednu obyč FPU. Geniální řešení.

A víte proč tohle nejde? Protože CPU má třeba 32 obecných registrů kam se těch 65tis hodnot pole/vektoru nevejde. Ale jde to obejít. Musel by se multiplikovat taky i Load instrukce, která by posouvala pointer o +1 s každou iterací. Taky by tam musela být i Store instrukce pro uložení vysledků. Byl by to takový mutliplikovaný blok instrukcí, což je proveditelné, prostě bude druhá multiplikační instrukce, která nastaví speciální registr pro počet instrukcí v tomto bloku a zase pro 16-bit to může být až 65 tisíc instrukcí. Nebo to vmáčknout vše do těch 16-bitů, 10-bitů pro délku vektoru 1024 (což *FP64 = 65536-bit SIMD registr ekvivalent, to by mělo stačit) a těch zbývajících 6-bitů dává 64 možností délky bloku instrukcí. Dále je problém s gather a scatter instrukcemi, ale i to je řešitelné - posouvat poiter toho gather/scatter vectoru lze posouvat tím multiplikátorem. Stejně jdou řešit i matice a více rozměrná pole. Místo obludného Intelovského AMX, které vzalo AVX512 registry, znásobilo jejich počet 16x a tím je uspořádalo do matic (oni tomu říkají Tiles). Přitom stačí jeden FP64 registr z kterého uděláš chytrým způsobem výpočet matice třeba 1000x 1000.

Jenže vracet se a měnit celý koncept se nikomu nechce. Vem si že bys tím přišel o kompatibilitu se 128-bit NEON, kdybys místo toho dal jen 32x FP64 registrů. Takže by museli podporovat obé. Intel by ztratil hůl na AMD v podobě vydávání nových SIMD, kterým musí uzpůsobovat HW což trvá roky vývoje.