Názory k článku Specifické vlastnosti procesorů AArch64: základní instrukce

v „pravých“ RISCových procesorech je zvykem používat všechny pracovní registry shodným způsobem

Ale AArch64 zde má taky omezení. Až se autor dostane k ASIMD nebo SVE/SVE2, tak zjistí, že u některých instrukcí není možné adresovat všechny registry. SVE má např. 16 "predicate" registrů, ale většina SIMD instrukcí, které jsou "predicated" umí adresovat jen 8 spodních. Instrukce, kde se používá index "V[index]" umí adresovat jen 16 nebo 8 spodních registrů, atd...

to je asi omezení délky instrukcí na 4 bajty? nebo něco hlubšího v architektuře?

hmm to je dobra otazka, ale spis to bude omezeni nejakych vnitrnich sbernic

Jo omezení na 4B - toho místa moc není a musí si nechat prostor pro nové rozšíření. Třeba zmíněné SVE/SVE2 je celkem masivní, možná i větší než celé AVX-512.

To je pravda a otázka je, jestli to byl dobrej nápad si zaplácat poměrně velkej prostor už teď (možná by se hodila i jiná rozšíření, nějaký WLIW+DSP třeba?). Ale uvidíme.

Tak třeba u nějakých budoucích rozšíření použijí pro příslušné instrukce délku 64 bitů.

njn assembler... jako chápu tak trochu co to dělá, ale z těch movů moudrej nejsem už od atárka...
Ale jinak pěkný článek. Díky za něj :)

MOV je prostě jen jinak zapsaný přirazení :-) A tuším 6502 MOVy neměla, takže asi myslíš Motorolácký atárka?

Jasný, už nevim co jsem tam tehdy vlastně naklapal - přepisoval jsem nějaký kód z časopisu, nebo z takový nějaký brožurky... A snad to i dělalo to co mělo...
Vzhledem k tomu, že jsem neměl tucha proč, další pokusy jsem v assembleru (nadobro) vzdal.

Ty (resp. M68k) je měly taky. Akorát z nějakého důvodu že zapisovaly MOVE místo MOV, ačkoli jinak tam drtivá většina instrukcí měla taky tradiční tři písmena.

Kratky pohlad na napr. https://web.njit.edu/~rosensta/classes/architecture/252software/code.pdf ti nedava velmi zapravdu. 3 pismena maju fakt len tie uplne najzakladnejsie instrukcie (and, add, sub, eor, ...), vacsinou su to 4-pismenove zapisy (samozrejme, assembler akceptuje and #123 a spravi z toho interne andi #123, ale niekedy je lepsie rozlisovat add/adda/addi/addq pre prehladnost).

Potom su tu samozrejme FPU instrukcie, tam uz aj 4 pismena su malo. :)

Assembler som voľakedy zbožňoval. Napísal som v ňom celkom dosť riadkov, dokonca aj funkčný kompilátor Forth. Samozrejme nemal na fig-Forth a podobné, ale bol môj, fungoval a zaberal cca 2kB, takže nebol problém ho používať na urýchlenie Basicu.
Na presuny som používal LD, takže je jasné že som písal na Zilog, konkrétne ZX-Spectrum, ale inštrukcie MOV mi nie sú neznáme, viackrát som prepisoval a upravoval rutiny pôvodne napísané pre Intel 8080.
Ďakujem za článok, pekne som si počítal a väčšine kupodivu aj rozumel. V assembleri som robil ešte v 80-tych rokoch.

Díky. Já si tehdy nejvíc hrál s MOS 6502, ale popravdě to byla hodně ruční práce (překlad na papíře :-). A potom s BOBO.

V assembleru jsem nikdy nic nenapsal ale fascinuje mě ten přístup přímo k jádru věci :-)
Třeba jak ten kompilátor pozná, že zrovna v x8 registru je to číslo služby. To kdybych psal já, tak bych ho určitě dal do x9 a byl bych v pytli :-p

Kompilátor nic nepoznává a téměř nic nekontroluje.
Ostatně, v dobách, kdy všechno muselo mít české názvy, se assembler jmenoval "jazyk symbolických instrukcí", eventuelně "jazyk symbolických adres" a kurs, kde se to učilo, se sice lidově nazýval Assemblery, ale oficiálně "Strojově orientované jazyky".
Kontroluje tak nanejvýš, zda se neodkazujete mimo rozsah nějakého segmentu nebo stránky (podle architektury procesoru). A kdo chvíli programuje (případně zkoumá nějaký kód bez zdrojáku) u jednodušších procesorů za chvíli může ten hexdump číst rovnou.
Pak pár let děláte něco jiného a schopnost se, pochopitelně, vytratí.

Díky za zajímavý článek. Vlastně se divím, proč má Aarch64 zároveň MOV a nulový registr, když v tom případě by se místo MOV X1,X2 mohlo dělat ADD X1,X2,XZR a ušetřila by se tím jedna instrukce. Matně si vzpomínám, že na některých architekturách to tak je (že by MIPS?)

A připadá mi škoda, že když už navrhli celou novou ISA, tak zůstali u 128 bitového SIMD. Mít 256 bitové registry jako AVX by bylo umožnilo pracovat se 4D vektory ve dvojí přesnosti, což by se zrovna u grafiky docela hodilo.

AArch má mov jen pro immediate (konstanty), ostatní mov instrukce jsou jen aliasy jiných instrukcí (ADD, ORR, možná další).

AArch má SVE/SVE2, což je rozšíření, ve kterém délka vektoru není známá. Ale jo, místo 64-bit a 128-bit SIMD mohli už tehdy navrhnout 128-bit a 256-bit - možná by SVE nebylo pak potřeba.

Díky za vysvětlení

This instruction is an alias of ORR (shifted register).
The equivalent instruction is ORR Wd, WZR, Wm.

SVE/SVE2 jsou spíš na numerické výpočty, AI apod, a tam ani 4*SIMD nestačí. Neon je pořád dobrá varianta na 3D grafiku (i když třeba na násobení pole vektorů maticí by taky bylo SVE užitečné) a 3D grafika si obvykle vystačí se single precision.

Vtipné je, že i přes fixed length instrukce je třeba kód pro násobení 4*4 matic kratší než x86_64 nejlepší varianta v AVX-512 - aarch64 to tam vyhrává díky instrukci vfmaq_laneq_f32, která násobí vybraným prvkem vektoru, navíc u x86_64 s každou verzí roste počet prefixů pro rozlišení instrukce. Kdysi jsem experimentoval: https://github.com/kvr000/zbynek-cxx-exp/blob/master/simd/matrix-multiplication/src/main/cxx/MatrixMultiplicationBenchmark.cxx#L439-L460 . Na rychlost ale stále o cca 60% zaostává (nebo zaostával v době aktuální pro měření)...

Nestaci pro AI kratsi floaty?

SVE2 má plně nahradit ASIMD (NEON) - aspoň tak to popisuje samotný ARM.

V X86 už moc prostoru pro další prefix není (existuje tuším už jen jediný byte). Takže EVEX je asi jeden z posledních :)

Ledaže by ten poslední byte znamenal, že následující byte volí z dalších 256 možností ;)

Je to přesně jak píše **anonacct**. Já to ještě nezmiňoval, protože jsme si zatím vystačili s mov registr, konstanta, ale přesně tak - mov registr, registrs je pseudoinstrukcí. Stejně jako třeba CMP=SUBS s výsledkem ukládaným do XZR. Assemblery to rozpoznají (to asi není překvapivé), ale i disassemblery taky (objdump atd.) a to je fajn v praxi.