7
« kdy: 23. 10. 2021, 22:47:53 »
Resim aktualne takovy problem, jehoz vystup asi uplne nepotesi priznivce RISC-V ekosystemu (nebo ukaze nejakou moji neznalost). Pomoci velmi podmineneho prekladu s gcc ( -Os ) vytvarim 'code snippety', ktere nasledne nejaky automat bude skladat za sebe (jde o dynamicky translator). Protoze chci zjistit, jestli to bude pouzitelne i jinde nez v x86 svete, nasbiral jsem ruzne prekladace a zkusil tyto code snippety vygenerovat pro ruzne architektury. Zde je vysledek; pocet vygenerovanych instrukci pro nejakou sadu tech snippetu; cim nizsi, tim kratsi kod. CISC je zde zvyhodnen, protoze instrukce hlavne u x86_64 jsou mnohem delsi nez jinde, hlavne u ARM (thumb2). Co jsem zkoumal vystup, obvykle vic instrukci rovna se i vyrazne mene optimalni kod a zbytecne zonglovani s daty.
10527 report-arm-noflags.txt (thumb2)
10938 report-armv8-noflags.txt
11209 report-x64-noflags.txt
12311 report-ppc32-noflags.txt
12371 report-sparc64-noflags.txt
12809 report-xtensa-noflags.txt
13036 report-x86-noflags.txt
14718 report-mips32-noflags.txt
16903 report-rv32-noflags.txt
18407 report-rv64-noflags.txt
Mam jeste jednu sadu, kde se vyhodnocuji nejake operace, to pridava ale do vetsiny snippetu celkem dost podobneho kodu, ktery by sel resit za pouziti flagu (cf/of/if) kdyby to gcc umelo lepe (typicky pushf a pozdeji v kodu popf pro nasledne snadne zpracovani ruznych overflow/carry/apod.). Spis jen pro priklad vlozim i to:
13151 report-x64-flags.txt
13225 report-arm-flags.txt
15175 report-ppc32-flags.txt
15535 report-x86-flags.txt
15770 report-sparc64-flags.txt
17118 report-xtensa-flags.txt
22410 report-rv32-flags.txt
23900 report-rv64-flags.txt
Krome RV64 a mam i realne zelezo, tak mohu porovnat i vysledky v rychlosti, nejak upravene na nejake MHz procesoru (xtensa je ESP32 LX6, tezko srovnavat primo s PowerPC nebo x86 dospelym pocitacem).
Nicmene mam i otazku. GCC mi generuje kod, ve kterem se skace a rutina nekonci nejakym "ret/blr", priklad (ppc32):
0: 94 21 ff e0 stwu r1,-32(r1)
4: 7c 08 02 a6 mflr r0
8: 90 01 00 24 stw r0,36(r1)
c: 93 e1 00 1c stw r31,28(r1)
..
48: 7d 4a 40 39 and. r10,r10,r8
4c: 41 82 00 18 beq 64
50: 48 00 00 01 bl 50
50: R_PPC_REL24 spec_read
54: 7c 7f 1a 14 add r3,r31,r3
58: 98 7d 00 00 stb r3,0(r29)
5c: 39 61 00 20 addi r11,r1,32
[b] 60: 48 00 00 00 b 60 <exec86+0x60>
60: R_PPC_REL24 _restgpr_31_x (!!!)[/b]
64: 81 3d 00 2c lwz r9,44(r29)
68: 7c 69 18 ae lbzx r3,r9,r3
[b] 6c: 4b ff ff e8 b 54 [/b]
Na adrese 60 je netypicke ukonceni (dusledek -Os), kazdopadne i kdyby tam bylo blr, nekonci tim rutina. Ja bych potreboval, abych z konce rutiny (0x6c) mohl jen odriznout blr a nebyl tam nejaky odskok "nahoru". A tim by slo trivialne retezit snippety za sebe v dynamicky generovanem kodu. Tusite jak k necemu takovemu primet gcc? Nedela to jen na powerpc, ale i jinych architekturach, typicky ARM. Reseni by bylo "linearizovat" kod, aby sel odshora dolu, a neskakal si nekam vzhuru. Jenze to musim naprogramovat. Dale bych uvital, kdybych nejak prekladaci umel rici, aby se treba vyvaroval nejakeho konstruktu, treba nejake relokaci, apod. Diky za pripadne tipy.
Prekvapenim je RISC-V, ktery ciselne, ale i pohledove generuje pomerne sileny kod. Tam, kde ma ARM uz spocitano, se risc-v potaci nekde v tom jak vidlemi prehazovat data... registru ma pritom mnohem vic RISC-V.