MyJIT: virtualni stroj pro novou generaci (diskuse)

[fraxinus]

Nejaky cas dozadu tu niekto robil v c++ nejaky jit pre nejaku graficku kniznicu

[deda.jabko]

jo, to byl dark nez tu spachal digitalni sebevrazdu. ta knihovna se tusim jeste vyviji, ale je vcelku vazana na x86 a ruzne mmx (a tusim i sse) operace. a treba portovat to na SPARC, coz je jedna z architektur, kterou pouzivam by byla asi sebevrazda.

s tim co pouzivam, navic byla vyhoda, ze jsem mohl vzit existujici kod, nad kterym jsem stravil urcity cas a ktery pouziva gnu lightning a vcelku primo jej prevest, tak aby zacal pouzivat mou knihovnu a s ni i ruzna vylepseni.

[Jardík]

AsmJit, BlitJit, Fog (jednou to bude nejlepší toolkit na světě )

BTW bacha na volací konvence, být tebou, tak je explicitně uvádím, nikdy nevíš, co má kompilátor nastaveno jako výchozí a obzvláště u té vygenerované fce bys to měl uvést.

[deda.jabko]

BTW bacha na volací konvence, být tebou, tak je explicitně uvádím, nikdy nevíš, co má kompilátor nastaveno jako výchozí a obzvláště u té vygenerované fce bys to měl uvést.

vim o tom. ale je to vec, kterou budu resit spolecne s porty na jine architektury. momentalne su rad, ze se to dostalo do stavu, kdy to bez vetsich problemu bezi na i386/linux a jdou s tim kompilovat realne programy.

[__dark__]

Knihovna se vyvíjí a mám s ní velké plány. Právě dokončuju verzi 1.0, která má o hodně lepší syntax, která obsahuje virtuální registry (já tomu řákám proměnné) a linear-scan register allocator + FPU alokator (ještě není hotový).

Knihovna je sice hodně vázaná na X86, ale ty části jsou oddělené. AsmJit byl navržený od začátku pro práci s MMX a SSE2, ale není to podmínka (tomu co píšeš tedy nerozumím). Pokud budeš chtít ve tvoji knihovně časem přidat vektorové instrukce, tak budeš podle mě postupovat podobně.

Co se týče portování na jiné architektury, tak chci časem ARM (tak do půl roku si chci koupit nějaké opravdové zařízení, na kterém to otestuju).

Co se týče životnosti projektu, tak AsmJit je udržovaný projekt s malou komunitu, použitý i v komerčním prostředí, nebál bych se tedy o jeho konec. Začal jsem dostávat i donate.

Ještě bych dodal, že AsmJit je jen assembler (dalo byse říct, že to je databáze instrukcí a pár tříd naví), to není virtuální stroj. Pokud chce kdokoliv "virtuální instrukce" (tedy stejné instrukce a registry pro různé architektury), musí si tu mezivrstvu naprogramovat. Až bude AsmJit podporovat různé architektury, tak tato vrstva bude jeho součástí, teď to ale nemá význam.

AsmJit

[deda.jabko]

Knihovna se vyvíjí a mám s ní velké plány. Právě dokončuju verzi 1.0, která má o hodně lepší syntax, která obsahuje virtuální registry (já tomu řákám proměnné) a linear-scan register allocator + FPU alokator (ještě není hotový).

good. tak to ja jsem virtualni registry zavedl hned ze zacatku. hlavne proto, aby vygenerovany kod zacal rovnou vyuzivat moznosti cilove architektury. coz s lightning nebylo dost mozne. mimochodem, jakym zpusobem resis ulozeni virtualni registru? kazda funkce ma sadu vlastnich registru (promennych) nebo jsou spolecne pro vsechen vygenerovany kod?

Knihovna je sice hodně vázaná na X86, ale ty části jsou oddělené. AsmJit byl navržený od začátku pro práci s MMX a SSE2, ale není to podmínka (tomu co píšeš tedy nerozumím).

jo, to bude nedorozumeni... podle toho co pises asmjit je na o neco mensi urovni abstrakce nez myjit. a prislo mi, ze ta podpora mmx a sse je tam vcelku zasadni... obzvlast, kdyz je to urcene pro praci s grafikou.

Pokud budeš chtít ve tvoji knihovně časem přidat vektorové instrukce, tak budeš podle mě postupovat podobně

zatim to neplanuju. ale je to navrzene tak, aby sly pridavat samostatne moduly pro optimalizace.

Co se týče portování na jiné architektury, tak chci časem ARM (tak do půl roku si chci koupit nějaké opravdové zařízení, na kterém to otestuju).

pro me je vcelku kriticky SPARC... o ARMu do budoucna uvazuju, ale zatim nemam potrebu, protoze taky nemam zadne zelezo.

Pokud chce kdokoliv "virtuální instrukce" (tedy stejné instrukce a registry pro různé architektury), musí si tu mezivrstvu naprogramovat. Až bude AsmJit podporovat různé architektury, tak tato vrstva bude jeho součástí, teď to ale nemá význam.

a proto je tu MyJIT :-]]

[__dark__]

good. tak to ja jsem virtualni registry zavedl hned ze zacatku. hlavne proto, aby vygenerovany kod zacal rovnou vyuzivat moznosti cilove architektury.

To moc nechápu, jak chceš využívat možnosti cílové architektury, když nemáš k dispozici fyzické registry? Architektura x86 je celkem drsná v tom, že některé instrukce (třeba mul, div, idiv) používají konkrétní registry (eax, edx). Ale i jiné, například všechny instrukce pro bitový posun (shl, sal, rol, ...).

Jak toto řešíš?

mimochodem, jakym zpusobem resis ulozeni virtualni registru? kazda funkce ma sadu vlastnich registru (promennych) nebo jsou spolecne pro vsechen vygenerovany kod?

Nevím jak popsat do jedné věty :) AsmJit obsahuje 2 vrstvy pro generování kódu. První vrstva zvaná Assembler, ta nejnižší, obsahuje pouze fyzické registry a je to vlastně jen assembler pro C++ (Operand může být Register, Memory address, Immediate nebo Label). Pomocí této vrstvy může člověk naprogramovat podle mě cokoliv.

Druhá vrstva je na vyšší úrovni (nazvaná Compiler). Místo fyzických registrů se používají právě ty virtuální (v AsmJit to je Variable, konkrétně GPVar, MMVar a XMMVar) a serializace instrukcí probíhá generováním tzv. Emittable_s (Emittable je nějaký objekt, který může vygenerovat nula, jednu nebo více instrukcí v Asm, může to být instrukce, label, funkce, prolog, atd...). Až je fáze generování kódu hotová, tak se zavolá make() a alokátor registrů zjistí minimální a maximální pozici (offset) všech proměnných, alokuje registry (alokování je v AsmJit změna operandu z VARIABLE na REGISTER), alokuje stack pro funkce a vygeneruje potřebný prolog a epilog funkcí.

Ve staré verzi AsmJit to fungovalo trochu jinak, alokování registrů probíhalo už při generování kódu, ale toto se mi hodně dlouhou dobu nelíbílo, tak bylo na čase to přepsat:)

Jinak architektura AsmJit byla také navržena s ohledem na rozšiřování, například se uvažuje nad pluginem, co provede instruction reordering ve výsledném kódu (toto je třeba vlastnost, která má pro tebe nulovou hodnotu, ale pro optimalizování kódu v inner loops je to celkem výhodné:) ).

jo, to bude nedorozumeni... podle toho co pises asmjit je na o neco mensi urovni abstrakce nez myjit. a prislo mi, ze ta podpora mmx a sse je tam vcelku zasadni... obzvlast, kdyz je to urcene pro praci s grafikou.

To se stává:) AsmJit je opravdu na hodně nízké úrovni, ale když člověk použije AsmJit::Compiler, tak se dají jednoduše udělat i celkem netriviální úlohy.

zatim to neplanuju. ale je to navrzene tak, aby sly pridavat samostatne moduly pro optimalizace.

Až budeš mít nějakou zajímavou, tak o tom napiš, třeba mě to k něčemu inspiruje:)

pro me je vcelku kriticky SPARC... o ARMu do budoucna uvazuju, ale zatim nemam potrebu, protoze taky nemam zadne zelezo.

Kdybych takové železo měl k dispozici (SPARC), tak by to podle mě nebyl problém dopsat. Co jsem si prohlížel různé JIT, tak nejkomplikovanější architektura je asi x86 a amd64, a ty jsou naštěstí hotové No budu postupovat tak, že až bude naprosto kompletní podpora pro x86/amd64, tak začnu s podporou jiných architektur.

Škoda, žes začal psát vlastní JIT, kdybys mě kontaktoval, tak jsme mohli navrhnout něco mnohem lepšího - mě osobně by nevadilo přidání virtuálních instrukcí do AsmJit:) Hlavně by se projekt mohl zase posunout o kus dál.

[deda.jabko]

To moc nechápu, jak chceš využívat možnosti cílové architektury, když nemáš k dispozici fyzické registry? Architektura x86 je celkem drsná v tom, že některé instrukce (třeba mul, div, idiv) používají konkrétní registry (eax, edx). Ale i jiné, například všechny instrukce pro bitový posun (shl, sal, rol, ...).

primarne vychazim z toho, ze vsechny registry jsou ,,virtualni'' a o prirazeni fyzickym registrum se postara alokator, uzivatel to nema sanci nijak ovlivnit. to je dobre z toho pohledu, ze programator se nemusi starat o to, jestli ma cilova architektura 6, 16 nebo 32 registru.

ten problem s instrukcema typu mul/div/etc. resim tak, ze pokud operace meni dany fyzicky registr a ten se zrovna pouziva, tak se hodnota v nem odsune do pameti nebo na zasobnik. neni to sice nejoptimalnejsi, ale tyto operace se v kodu, co pouzivam nevyskytuji prilis casto. navic treba o cast nasobeni se postaraji operace jako lea, shl, etc.

alokuje stack pro funkce a vygeneruje potřebný prolog a epilog funkcí.

je toto thread-safe? i.e., kdyz zavolas tu samou funkci 2x paralelne neperou se ti o pristup k registrum? ja osobne jsem mel s rozumnym umistenim ,,virtualnich registru'' docela problemy a nakonec kazda funkce musi mit svou sadu registru na zasobniku alokovanou kdykoliv je zavolana. ...proto se ptam.

Kdybych takové železo měl k dispozici (SPARC), tak by to podle mě nebyl problém dopsat. Co jsem si prohlížel různé JIT, tak nejkomplikovanější architektura je asi x86 a amd64, a ty jsou naštěstí hotové

u jinych architektur je spis problem, ze jsou jine. u toho sparcu je to naprosto jiny pristup k praci s registry a zasobnikem nez ma x86, proto jsem rovnou zacal s intermediate language a ne s nadstavbou nad x86... a taky, ze mi to vyrazne zjednodusi portovani za cenu horsich optimalizaci.

Škoda, žes začal psát vlastní JIT, kdybys mě kontaktoval, tak jsme mohli navrhnout něco mnohem lepšího - mě osobně by nevadilo přidání virtuálních instrukcí do AsmJit:) Hlavně by se projekt mohl zase posunout o kus dál.

zvazoval jsem i tuto alternativu. ale nakonec jsem rozhodl pro vlastni projekt... protoze ve sve podstate jsem chtel jen neco mezi libjit a lightning. ale bylo tam i jine duvody, mj. ze je to v C++. coz je tak trochu osobni vec a tak trochu technicka. pocitam s tim, ze na MyJIT budu mit bindingy primo ze Schemika a cast prekledace Schemika bude napsana v nem... s C++ by se neco takoveho vcelku komplikovalo.

nicmene urcite bych se nebranil nejake spolupraci... at uz na urovni vymeny zkusenosti nebo primo vymeny kodu. napr. mam v planu zaclenit primo disassembler jako soucast debugovacich nastroju. pokud uz neco takoveho nemas, verim, ze bys to uzivil.

[__dark__]

je toto thread-safe? i.e., kdyz zavolas tu samou funkci 2x paralelne neperou se ti o pristup k registrum? ja osobne jsem mel s rozumnym umistenim ,,virtualnich registru'' docela problemy a nakonec kazda funkce musi mit svou sadu registru na zasobniku alokovanou kdykoliv je zavolana. ...proto se ptam.

Tomu nerozumím. Proměnné se přece alokují na zásobníku (tedy esp, rsp), takže pokud je vygenerovaná funkce thread-safe, tak nevidím nikde problém. Jinak AsmJit knihovna je reentrant, funkce pro správu virtuální paměti jsou thread-safe.

u jinych architektur je spis problem, ze jsou jine. u toho sparcu je to naprosto jiny pristup k praci s registry a zasobnikem nez ma x86, proto jsem rovnou zacal s intermediate language a ne s nadstavbou nad x86

Nedovedu si představit, jak moc je to jiné:)

zvazoval jsem i tuto alternativu. ale nakonec jsem rozhodl pro vlastni projekt...

Typické, dělám to taky:)

protoze ve sve podstate jsem chtel jen neco mezi libjit a lightning. ale bylo tam i jine duvody, mj. ze je to v C++. coz je tak trochu osobni vec a tak trochu technicka. pocitam s tim, ze na MyJIT budu mit bindingy primo ze Schemika a cast prekledace Schemika bude napsana v nem... s C++ by se neco takoveho vcelku komplikovalo.

To beru, ale moc nechápu, v čem by se to v C++ mohlo komplikovat? AsmJit má celkem silné API, a to co člověk používá jsou jen inline funkce, které volají velmi malý počet virtuálních. Pomocí AsmJit by se dal velmi jednoduše udělat assembler, který přechroustá textový soubor (databáze instrukcí obsahuje i jejich jména a AsmJit před zapsáním instrukce do výsledného streamu provede i validaci). Právě návrh celé knihovny byl jeden z důvodů, proč jsem napsal AsmJit, a C++ překladač do generování kódu vkládá i typovou kontrolu.

nicmene urcite bych se nebranil nejake spolupraci... at uz na urovni vymeny zkusenosti nebo primo vymeny kodu.

No problem. Kdybys něco někdy potřeboval, tak mi klidně napiš mail.

napr. mam v planu zaclenit primo disassembler jako soucast debugovacich nastroju. pokud uz neco takoveho nemas, verim, ze bys to uzivil.

Toto chci řešit jinak. Nová verze AsmJit obsahuje možnost vypsání instrukce ve formě:

instrukce ; binární podoba | komentář

Ve spojení s loggerem může výpis vygenerovaného asm vypadat třeba takto:

C++ kód:

using namespace AsmJit;

Compiler c;

FileLogger logger(stderr);
c.setLogger(&logger);

c.newFunction(CALL_CONV_DEFAULT, 
  FunctionBuilder3<void*, void*, sysuint_t>());
c.getFunction()->setHint(FUNCTION_HINT_NAKED, true);

GPVar dst(c.argGP(0));
GPVar src(c.argGP(1));
GPVar cnt(c.argGP(2));

c.rep_movsb(dst, src, cnt);
c.endFunction();

c.make();

Log:

; Function Prototype:
;
; IDX| Type     | Sz | Home            |
; ---+----------+----+-----------------+
; 0  | GP.Q     | 8  | rdi             |
; 1  | GP.Q     | 8  | rsi             |
; 2  | GP.Q     | 8  | rdx             |
;
; Variables:
;
; ID | Type     | Sz | Home            | Register Access    | Memory Access      |
; ---+----------+----+-----------------+--------------------+--------------------+
; 0  | GP.Q     | 8  | [None]          | r=1   w=0   rw=0   | r=0   w=0   rw=0   |
; 1  | GP.Q     | 8  | [None]          | r=1   w=0   rw=0   | r=0   w=0   rw=0   |
; 2  | GP.Q     | 8  | [None]          | r=0   w=0   rw=1   | r=0   w=0   rw=0   |
;
; Modified registers (4):
; GP : rcx, rdx, rsi, rdi
; MM : 
; XMM: 

L.0:
; Function prolog
; Function body
mov rcx, rdx
rep movsb
L.1:
; Function epilog
ret
*** COMPILER SUCCESS (wrote 6 bytes).

Logger může vygenerovat i následující výstup (zobrazuji jen tělo):

mov rcx, rdx                    ; 488BCA
rep movsb                       ; F3A4
ret                             ; C3

Nechci si fandit, ale toto s knihovnama typu gnu lighting nebo libjit, kde je tuna maker a generovaný kód je vlastně inlinován do bufferu, asi nikdy neuděláš. Navíc u tvého kódu pociťuju i jistou nebezpečnost přetečení bufferu. V AsmJit nic takového nemusíš řešit, virtuální paměť je alokovaná automaticky a počet registrů není nijak omezený. Ta maximální velikost funkce u MyJIT mi přijde nejvíc ošemetná - například pro architekturu amd64 bude funkce s největší pravděpodobností větší, než u x86, a chytat přetečení bufferu není zrovna relaxační činnost:)

Každopádně přeju hodně úspěchů s MyJIT, jelikož jsem podobný projekt napsal, tak tě můžu jen varovat, že to spolkne moře hodin

[deda.jabko]

Tomu nerozumím. Proměnné se přece alokují na zásobníku (tedy esp, rsp), takže pokud je vygenerovaná funkce thread-safe, tak nevidím nikde problém.

jo, tak to jsme si zase nerozumeli... nevadi.

Nedovedu si představit, jak moc je to jiné:)

nekdy se na to mrkni, je to vcelku zajimave a prijde mi, ze u toho lidi od sunu docela premysleli.

To beru, ale moc nechápu, v čem by se to v C++ mohlo komplikovat? AsmJit má celkem silné API, a to co člověk používá jsou jen inline funkce, které volají velmi malý počet virtuálních.

jednak kod se kterym pracuju v Schemiku je v cistem C a rozhrani pro rozsirovani taky pocitaji s ceckem. jo, sly by udelat bindingy pro tu knihovnu... ale byla by to hromada vaty. myjit k zacleneni do cehokoliv staci asi pet funkci. zbytek je ve skutecnosti reprezentovany jednou ,,univerzalni'' funkci.

Nová verze AsmJit obsahuje možnost vypsání instrukce ve formě:

to je tim, ze asmjit pracuje na trochu nizsi urovni... coz je plus i trochu minus.

Nechci si fandit, ale toto s knihovnama typu gnu lighting nebo libjit, kde je tuna maker a generovaný kód je vlastně inlinován do bufferu, asi nikdy neuděláš.

jo, to je jeden z duvodu, proc jsem se pustil do nove verze knihovny. myjit sice obsahuje hromadu maker, ale slouzi jenom k vytvoreni API. zbytek je pod kontrolou.

Navíc u tvého kódu pociťuju i jistou nebezpečnost přetečení bufferu.

vim o tom, je to jedna z veci, ktere chci opravit a jejichz reseni existuje a je vcelku jednoduche, ale chce to svuj cas. (toto je uplne prvni release)

Každopádně přeju hodně úspěchů s MyJIT, jelikož jsem podobný projekt napsal, tak tě můžu jen varovat, že to spolkne moře hodin

diky, napodobne.

[Stanislav Bohm]

LibJIT ma pomerne hezke debug vypisy. Bud primo v asm, nebo i v podobe virtualniho kodu

function FCN(i1 : ptr, i2 : ptr) : ptr
	incoming_frame_posn(i1, 8)
	incoming_frame_posn(i2, 12)
	i6 = &s5
	i8 = load_relative_int(i2, 0)
	store_relative_int(i6, 134793016, 0)
	store_relative_int(i6, 134746992, 4)
	store_relative_int(i6, 0, 8)
	push_int(i6)
.L2:
	call_external send_message (0x08054ac0)
	return_reg(i14, eax)
	pop_stack(4)
	if itrue(i14) then goto .L0
.L3:
	push_int(0)
	push_int(i6)
	push_int(134796856)

(zacated debug vypisu zakompilovane metody z meho JIT compileru pomoci libJIT)

[deda.jabko]

shodou okolnosti toto myjit umi taky (i kdyz je to momentalne trochu rozbite) a pres objdump umi udelat i vypis vygenerovaneho kodu... ale porad to neni ono... mojim cilem, je to mit vsechno hezky propojene. ;-]

[Stanislav Bohm]

Kdyz jsem si hral s JIT prekladacem do sveho jazyka (Kreatrix, kdyz uz se tu muzu pochlubit:) Tak jsem taky vybiral z LLVM, LibJIT a lightning. LLVM mi taky prisel jako kanon na vrabce a lightning jsem po experimentovani vyradil kvuli tem omezenym registrum. LibJIT mi prijde jako docela pekna knihovna a implementovat JIT kompiler nebyl zadny vetsi problem. Co si tak ale matne pamatuji, tak tech backendu to umelo vice, ne jen i386 a x86-64 (ale mozna si to pamatuji spatne). Dopsat dalsi backend nevypadalo zas nejak extra slozite (ale nezkousel jsem). Vyvoj pred rokem kdyz jsem si s tim hral neprekypoval zivotem a obcas nejaky patch v mailing listu proletel.

[deda.jabko]

Kdyz jsem si hral s JIT prekladacem do sveho jazyka (Kreatrix, kdyz uz se tu muzu pochlubit:)

good!

LLVM mi taky prisel jako kanon na vrabce a lightning jsem po experimentovani vyradil kvuli tem omezenym registrum.

lightning i pres ty omezene registry sel vcelku slusne pouzivat. ale bylo to trochu nepohodlne a to me stvalo. mimochodem, kdyz jsem si hral s alokatorem registru, tak me vetsinou ukazoval, ze mu bohate staci 5 registru.

Vyvoj pred rokem kdyz jsem si s tim hral neprekypoval zivotem a obcas nejaky patch v mailing listu proletel.

mne prislo, jak kdyby libjit existoval v nekolika instancich (libjit, libjit-linear-allocator a to co je v dotgnu), kde se kazda pohybuje vlastnim smerem a tempem. coz ve me nebudilo moc duveru. jinak si myslim, ze ta knihovna je navrzena docela dobre.

[Stanislav Bohm]

lightning i pres ty omezene registry sel vcelku slusne pouzivat. ale bylo to trochu nepohodlne a to me stvalo. mimochodem, kdyz jsem si hral s alokatorem registru, tak me vetsinou ukazoval, ze mu bohate staci 5 registru.

Me se prave moc nechtelo hrat s alokatorem registru atp. Pomoci libJIT to slo udelat celkem jednoduse, protoze mi stacilo jen "vykonavat" bytecode, ale misto provadeni operaci se vola libJIT. Diky to mu ze jsem se nemusel starat o registry tak to slo celkem primocare.

mne prislo, jak kdyby libjit existoval v nekolika instancich (libjit, libjit-linear-allocator a to co je v dotgnu), kde se kazda pohybuje vlastnim smerem a tempem. coz ve me nebudilo moc duveru. jinak si myslim, ze ta knihovna je navrzena docela dobre.

Pamatuji si ze jsem mel problem vlastne urcit co je hlavni domovska stranka projektu, ale pouzival jsem nejakou verzi, od Demakova a ta fungovala bez problemu.

[deda.jabko]

Me se prave moc nechtelo hrat s alokatorem registru atp.

ja jsem se toho puvodne taky docela bal, ale nakonec se ukazalo, ze to neni takova hruza. a treba ten alokator je vec asi na 300 radku. v soucasne dobe je vcelku primitivni zalozeny na uvolnovani registru podle LRU, ale i presto, ze se obcas sekne, tak casto je schopen rozhodit registry lip nez ja.

Pamatuji si ze jsem mel problem vlastne urcit co je hlavni domovska stranka projektu, ale pouzival jsem nejakou verzi, od Demakova a ta fungovala bez problemu.

no, prave. ja mam prave docela drsne zkusenosti s knihovnama tretich stran... a nerad bych treba v tomto pripade zjistil, ze vyvoj knihovny se po jednom nebo dvou letech zastavil a nikdo nedela ani opravy. navic myjit je tak trochu i pokus, jak udelat alternativu ke gnu lightning a libjit... ktere maji sve neduhy.

[Stanislav Bohm]

Ze by ty knihovny nejak umrely bych se nebal, myslim ze obe uz nabalily nejake ty uzivatele. LibJIT ma minimalne DotGNU a lightning je tusim v GNU Smalltalku. Rozhodne ale MyJIT fandim, protoze neco mezi LibJIT a lightningem mi pri mem pouziti chybelo. Snad jedine co bych mozna zvazil, je to dopredu dane mnozstvi registru. Na LibJIT se mi libil ten pristup ze mam "neomezene" mnozstvi registru do kterych jde zapsat jenom jednou. Pro alokator by to asi melo byt jedno, ale z hlediska API se s tim IMHO pracuje lepe.

[deda.jabko]

Ze by ty knihovny nejak umrely bych se nebal, myslim ze obe uz nabalily nejake ty uzivatele.

me uz se nekolikrat stalo, ze jsem zacal pouzivat nejakou knihovnu a po jednom/dvou letech jsem v ni objevil nejakou zasadni chybu, kterou neslo jednoduse opravit... a kdyz jsem se pidil po nove verzi, zjistil jsem, ze knihovnu uz nekolik let nikdo neudrzuje a nova verze proste nebude i kdyz ji spousta lidi pouziva. takze nezbyvalo nez prejit na neco jineho. :-/

Rozhodne ale MyJIT fandim, protoze neco mezi LibJIT a lightningem mi pri mem pouziti chybelo.

diky.

Snad jedine co bych mozna zvazil, je to dopredu dane mnozstvi registru.

diky za pripominku. toto je implementacni omezeni... a kdyz nad tim tak premyslim, tak se toho mozna bude dat zbavit. ono i s timto navrhem muzes bez problemu rict, ze se ma prekladac nachystat na to, ze budes pouzivat treba 1000 registru a bude to bez problemu fungovat, jenom trochu pomaleji. (i kdyz momentalne je tam umele omezeni na 32 registru, to budu muset brzo opravit)

Na LibJIT se mi libil ten pristup ze mam "neomezene" mnozstvi registru do kterych jde zapsat jenom jednou. Pro alokator by to asi melo byt jedno, ale z hlediska API se s tim IMHO pracuje lepe.

toto hodne souvisi s vnitrni architekturou generatoru kodu a umoznujeto nektere lepsi optimalizace. osobne se mi libi vic pristup, kdy muzu kteroukoliv promennou/register pouzit vickrat... prijde mi, ze je tak kod citelnejsi.

[Stanislav Bohm]

me uz se nekolikrat stalo, ze jsem zacal pouzivat nejakou knihovnu a po jednom/dvou letech jsem v ni objevil nejakou zasadni chybu, kterou neslo jednoduse opravit...

Otazkou ale zustava, jestli usili venovane do vlastniho reseni neni vetsi nez opravit chybu, i kdyz obtiznou. U sebe uz jsem parkrat na komplex Not-Invented-Here dojel:)

toto hodne souvisi s vnitrni architekturou generatoru kodu a umoznujeto nektere lepsi optimalizace. osobne se mi libi vic pristup, kdy muzu kteroukoliv promennou/register pouzit vickrat... prijde mi, ze je tak kod citelnejsi.

Me prijde reseni v LibJIT citelnejsi v tom ze nemusim resit co zrovna je v registru R5 ale muzu tu hodnotu mit v nejak rozumne pojmenovane promenne. Pripadne neresim jakou hodnotu budu jeste potrebovat a co zahodit. Ale to uz je asi otazka vkusu.

[deda.jabko]

Otazkou ale zustava, jestli usili venovane do vlastniho reseni neni vetsi nez opravit chybu, i kdyz obtiznou. U sebe uz jsem parkrat na komplex Not-Invented-Here dojel:)

zvazoval jsem i toto... na to su az prilis liny, abych se bezhlave poustel do tak velkych veci. ono se da na to divat i z druhe strany... diky vlastni knihovne muzeme mit jistou ,,konkurencni vyhodu''. napr. treba takovy ,,konkurencni'' mzscheme, pouziva gnu lightning, takze je jiste, ze nedokaze vyuzit vyhody 64bitovych procesoru...

Me prijde reseni v LibJIT citelnejsi v tom ze nemusim resit co zrovna je v registru R5 ale muzu tu hodnotu mit v nejak rozumne pojmenovane promenne. Pripadne neresim jakou hodnotu budu jeste potrebovat a co zahodit. Ale to uz je asi otazka vkusu.

to je nedorozumeni a mozna bych to mel dat do nejakeho tutorialu. to, ze se registr jmenuje R5, neznamena, ze si jej nemuzete pojmenovat jinak... treba "reg_index" technicky je to jenom cislo...

muzete pouzit:

#define reg_index (R(5))

// nebo 

int reg_index = R(5);
jit_addi(jit, reg_index, reg_index, 1);

pokud pouzivate funkce, ktere generuji slozitejsi operace, jdou s tim delat trochu triky.

o to jakou hodnotu budete potrebovat nebo kterou muzete zahodit se stara alokator registru. vy proste jen ten registr prestane pouzivat. registry v pojeti myjit maji bliz k promennym, nez k registrum procesoru.

[Stanislav Bohm]

Dekuji za detailnejsi popis. Takhle to vypada mnohem lepe. Ale uz je to jen krok od toho mit int reg_index = jit_next_reg(); misto konstantniho registru.

[deda.jabko]

technicky by to nemel byt problem. pouvazuju o tom. (zejmena, jestli se to hodi z pohledu koncepce)