Proc se vlastne pouzivaji ty bloky? Pripadne me prirozenejsi mit jeden nepodmineny skok (treba ten br nebo klidne jmp) a dejme tomu branch kdyz je TOS==0 a branch kdyz je TOS==1. To bohate staci uplne na vsechny pripady ne?
Protože nechtějí používat adresy.
Ale stejně tak by mohli používat symbolické adresy, labely jako u funkcí. Hold design decision
vsak staci pouzivat relativni skoky ne? Jako jasne, adresy tam nakonec jsou, ale to jsou i u tech bloku. musi se zapamatovat jejich zacatky a konce. Ale ok, mozna je za tim neco hlubsiho, mozna omezeni semanticke mezery...
jde o sémantiku, trošku to pomáhá i disassembleru atd. Možná i JITům, ale to je jen spekulace, protože JITy byly posledních cca 20 let optimalizovány na "skoky", takže to je asi už vyřešená věc.
Me to prijde jako semanticky cistejsi (psal jsem diplomku na tohle tema).
Skoky, at uz GOTO ci JMP jsou nehezke konstrukty, ktere maji tendenci porusovat viditelnost promennych, pokud mate v moci skakat na adresu, tak si musite dat pozor na skok doprostred instrukce (vivat viry a anti-disasm) a jine podivnosti.
Takze ta reprezentace vnorenych bloku, ktere pripomina XML, je celkem hezky aspekt WASM. A kod muze jit jen na pocatek nebo na konec bloku.
Samozrejme to obnasi nutnost proskenovat celej instrukcni flow, ale s tim se jaksi pocita, pokud to projde pres JIT preklad.
Jediny do ceho to haze vidle je onen switch-case, ze neexistuje nativni trampolina/vektorizovany jump, ale je treba ty bloky vnorovat (pripomina mi to problemaktiku parsovani vyrazu - zda se zavorkuje zleva nebo zprava :)
Někdy kolem roku 2000 jsme se spolužákem žádali Akademii věd o grant na vybudování úložiště a vyhledávače ve kterém by byly uloženy a zaindexovány všechny práce studentů a doktorandů.
Přišlo nám, že spousta zajímavých a potenciálně užitečných prací zahnívá v depozitářích univerzit.
Nevyšlo to, prý by to bylo pěkné, ale byl by to velký průšvih.
A to jsme chtěli na zorganizování, vybudování a několikaletý provoz jen cca 3M Kč.
Ty verejne digitalni kopie zavedli myslim par let po nas (koncil jsem 2006), my jen odevzdavali digitalni verzi do informacniho systemu skoly.
Pak jsem to mel chvili na osobnim webu - a nedavno jsem zkousel sluzbu na kontrolu plagiatu - odhalilo to prave jenom tenhle zdroj (tak nevim zda nascrapovali internet sami nebo je tam nejaka spoluprace s vyhledavaci) a casti abstraktu na webu skoly :D
Ty Bc/Mgr prace jako nemaj takovou hodnotu, obcas je to nutne zlo.. na vyssi stupni ale prace a papery existuji - kdyz je to podstata onoho studia. Bohuzel taky casto jen v placenych systemech, coz je skoda. Clovek by z toho rad cerpal.. nez to vymyslel sam, a pak ho narkli z toho ze to nekde okopcil az si projde sam tou narocnou casti.
Bc. a Mgr. práce jsou "občas" nutné zlo? Zvlášť Bc. práce jsou zlo a rozhodně ne občas. Ty Mgr. v mnoha případech také.
+1, asi se bude lépe optimalizovat logická struktura než náhodné skoky. A výhoda (nebo nevýhoda - jak pro koho) je snadnější disassembler zmíněný výše :-)
Právě. Zajímavé je, že tady se sám tváří trošku vysokoúrovňověji než JVM, kde skoky jsou. Ale musí se řešit právě tyto lahůdky jako skok doprostřed instrukce (JVM IIRC zakazuje) a viditelnost proměnných. JVM má celkem komplexní algoritmus verifikace, který řeší tyto srandy, a kterému se asi chtěli autoři wasm vyhnout. A k tomu už i pre-verifikaci, což stručně řečeno znamená, že v class souboru jsou navíc i informace, které je výpočetně jednodušší ověřit než odvodit. Původně pre-verifikace vznikla (zřejmě kvůli výkonu) pro J2ME, v jiné podobě (a možná ne pod tímto názvem) se objevila následně pro Javu SE (snad v 7 to ještě šlo vypnout a 8 to vyžaduje, pokud nemáme starou major verzi).
Pravda, wasm asi část věcí nemusí řešit (IIUC to má jednodušší s typy), ale i tak by stejný postup přinesl část painu.
Na SIMD ve WASM jsem zvědavý. Někde v dokumentaci jsem četl, že v Céčku je možné používat x86 intrinsics (asi jenom SSE2) a compiler (clang) to v pohodě přeloží do WASM. To má WASM 1:1 ekvivalentní instrukce jako x86? Nebo fungují pouze některé? Nebo fungují všechny ale výsledný bajtkód bude vypadat hrozně (protože to bude neefektivně emulovat)? Co když potom ta binárka poběží na ARM/NEON, nebude to pomalé? Mám zkušenosti pouze s integer SIMD (SSE2 až AVX512) a tam ten lineární nárůst výkonu lze snadno vidět.
Ano v céčku je možné používat intrinsics, ale i klidně se do SIMD přeloží i vektorové operace, tedy operace nad (například):
typedef float v16f __attribute__((vector_size(16)));
Omezeno je to většinou právě na 128bitové vektory s floaty, takže žádná ekvivalence s AVX nebo dokonce AVX 512 tam není, ale pořád lepší než nic. A právě kvůli tomu omezeni to dobře běží i s NEONy.