Temat: Generowanie kodu przez ILGenerator i Br

Problem w sumie bardziej akademicki, ale właśnie budując kod IL przez ILGenerator napotkałem problem, w jaki sposób generując skoki - Branch'e - z góry przewidzieć, czy mogę użyć wersji skróconej OpCodes.Br_S, OpCodes.Brtrue_S itd. Sam sobie odpowiem, że chyba to nie możliwe bo to w tym momencie ja a nie kompilator produkuję kod i sam powinienem wiedzieć, ile go naprodukuję.

A problem jest taki, że piszę funkcję która mnoży (skalarnie) dwa wektory, z czego jeden wektor jest ustalony, więc generuję dynamiczną funkcję, w której zakodowuję na sztywno współczynniki jednego wektora (aby było szybciej). Trudno mi oszacować długość kodu, ponieważ:
- jeżeli współczynnik wynosi 0 to w ogóle pomijam wyraz (bo nic nie wniesie do końcowej sumy)
- jeżeli współczynnik wynosi 1 to pomijam mnożenie, sumowanie zostawiam

Wymyśliłem bardzo brzydkie rozwiązanie: użyć Br_S i jak się nie skompiluje to przejść na Br.

Wiem, że zagadnienie mało praktyczne, ale w Święta nie zajmowałem się pracą tylko hobby:)

Temat: Generowanie kodu przez ILGenerator i Br

Też mi się wydaje, że musisz to sam zrobić. Taką treść znalazłem w Expert .NET 2.0 IL Assembler:

The high-level language compilers, emitting the IL code, automatically estimate the
ranges and choose whether a long form or a short form of the instruction should be used in
each particular case. The ILAsm compiler, of course, does nothing of the sort. If you specify a
long or short instruction, the compiler takes it at face value—you are the boss, and you are
supposed to know better. But if you specify a short branching instruction and place the target
label out of range, the ILAsm compiler will diagnose an error.

Zakładam, że dzieje się tak samo w przypadku ILGeneratora jak i ILAsm'a.

Rozumiem, że nie chcesz od razu emitować wersji 4-bajtowych ze względu na wydajność?

Temat: Generowanie kodu przez ILGenerator i Br

Paweł Łukasik:
Rozumiem, że nie chcesz od razu emitować wersji 4-bajtowych
ze względu na wydajność?

Tak - po to wchodzę a ILa aby było _super_ wydajnie w runtime. Te mnożenie wektorów o którym pisałem odbywa się dla każdego pixela na bitmapie o rozmiarze ok. 800x600 i fajnie byłoby się wyrobić w 1/30 sekundy aby uzyskać płynny obraz. Na dodatek dzieje się to w Silverlighcie, który działa trochę topornie.

Swoją drogą gratuluję wytrwałości w czytaniu "Expert .NET 2.0 IL Assembler" - książkę trzymam na półce na wszelki wypadek, ale nie udało mi się przez nią nigdy przebrnąć:)

Temat: Generowanie kodu przez ILGenerator i Br

maciek kański:

Paweł Łukasik:
Rozumiem, że nie chcesz od razu emitować wersji 4-bajtowych
ze względu na wydajność?

Tak - po to wchodzę a ILa aby było _super_ wydajnie w runtime. Te mnożenie wektorów o którym pisałem odbywa się dla każdego pixela na bitmapie o rozmiarze ok. 800x600 i fajnie byłoby się wyrobić w 1/30 sekundy aby uzyskać płynny obraz. Na dodatek dzieje się to w Silverlighcie, który działa trochę topornie.

Swoją drogą gratuluję wytrwałości w czytaniu "Expert .NET 2.0 IL Assembler" - książkę trzymam na półce na wszelki wypadek, ale nie udało mi się przez nią nigdy przebrnąć:)

Jeśli robisz operacje na pixelach w obrazie to nie lepiej użyć pointerów, jak ja tworzyłem algorytmy przetwarzania obrazów to wersja z pointerami była jakieś 30 razy szybsza. Zakładając oczywiście że już tak nie robisz :)

Co do Branchy to bezpieczniej wg mnie zawsze jest dawać OpCodes.Brtrue_S niż kombinować z wywalaniem się :) nie wiem ile bardziej jest to kosztowne ale nie powinno być aż tak bardzo.

Temat: Generowanie kodu przez ILGenerator i Br

Bartosz Adamczewski:
Co do Branchy to bezpieczniej wg mnie zawsze jest dawać OpCodes.Brtrue_S niż kombinować z wywalaniem się :)

Zapewne chciałeś napisać wersję bez _S:)

W ogóle straciłem bardzo dużo czasu na diagnozowaniu co nie działa w moim ILu generowanym pod SilverLighcie. Kod testowałem na normalnym projekcie .NET 3.5 (64bit) bo tam mogę łatwo zapisać wygenerowane assembly do pliku i podejrzeć Reflectorem (w celu diagnozy).
Okazało się, że w .NET 3.5 OpCodes.Ldc_I4_S przyjmuje poprawnie argumenty od -128 do 127, natomiast w SL4 działa poprawnie tylko w zakresie 9-127 (dla 0-8 korzystam z Ldc_I4_n) Kosztowało mnie sporo czasu zanim do tego doszedłem i ogólnie mogę podsumować moje doświadczenia, że te wszystkie wersje short_form są bardzo problematyczne, szczególnie przy przejściu .NET <-> SL