On 2013-05-08 23:15, Edek wrote:
> Dnia Wed, 08 May 2013 21:18:15 +0100 po głębokim namyśle Andrzej Jarzabek
> rzekł:

>> Osobiście doświadczeń nie mam, ale:
>> 1. Na stronie piszą, że " Despite its name, LLVM has little to do with
>> traditional virtual machines" i że nie jest skrótem od niczego, myślę,
>> że można sobie podarować wszelkie dalsze rozważania na temat tego w jaki
>> sposób LLVM jest VM.
>
> No ale jest VM. W tym sensie, że zapewnia istnienie LLVM IR, czyli
> odpowiednika assemblera. Skoro LLVM IR nie chodzi na żadnym prawdziwym
> procesorze tylko jest "assemblerem VM", mamy VM. A że to nie ma nic
> wspólnego z JVM czy .Net to oczywiste, przy czym to zupełnie osobne
> sprawy.
>

To kwestia terminologii. Ja przyjmuje z grubsza taka, ze "wirtualna
maszyna" to taki program, ktory pozwala na uruchomienie innych
programow. W tym sensie LLVM nie jest VM, bo programow nie uruchamia,
tylko robi ich translacje.
To ze LLVM IR moze stanowic zestaw instrukcji (bytecode) maszyny
wirtualnej jest inna sprawa. Tyle ze w zaleznosci od zastosowan,
bytecode maszyny wirtualnej jest projektowany inaczej.
Jak pisalem wczesniej Google probuje zbudowac maszyne wirtualna w
oparciu o LLVM IR. Ale - jak czytalem - natrafil na trudnosci
(przepraszam nie znam szczegolow) - wlasnie dlatego, ze LLVM IR byl
projektowany pod inne zastosowania.

--
Michal

do góry

On 09/05/2013 17:18, Edek wrote:
> Dnia Thu, 09 May 2013 12:59:20 +0100 po głębokim namyśle Andrzej Jarzabek
> rzekł:
>
>> No właśnie VM często się rozumie tak, że to jest środowisko, w którym
>> "chodzi" ten "assembler". LLVM IR w ogóle na niczym nie "chodzi", tylko
>> jest normalnie tłumaczone na kod maszynowy.
>
> No właśnie dlatego mówią, że nie VM w tradycyjnym znaczeniu. Niemniej
> sama zazwa wskazuje na to, czym llvm jest.

No więc jeszcze raz zauważę, że kolesie na stronie twierdzą, że nazwa to
jest po prostu LLVM i że to nie jest żaden skrót, który by się w
cokolwiek rozwijał.

>> Konkretnie na przykład biorąc jakiegoś Antlr-a czy coś podobnego i
>> generując IR na regulach produkcyjnych.
>
> W sumie. Od pisania na JVM różni się tym, że to nie jest Java tylko
> raczej C ze wszystkimi bindingami; od generowania assemblera
> prostsze i ma się za darmo optymalizacje. Tak czy inaczej pisze
> się kompilator odpowiednio skomplikowany do języka i haczyki runtime.
>
> Jeżeli to jest opinioa na podstawie przykładów, gdyby się znalazł
> jakiś fajny link chętnie bym obejrzał.

Tu jest podobne podejście - chociaż to zabawka w sumie:
https://archive.fosdem.org/2012/schedule/event/400/9
9_DSLsWithLLVM.pdf

Tutaj interesujące podejście o tyle, że sam DSL jest osadzony w Ruby
(języku było nie było interpretowanym), natomiast przy użyciu LLVM jest
kompilowany do kodu natywnego.
https://github.com/jvoorhis/Siren

Tu opis podejścia z ANTLR-em i Javą - tutaj zamiast bezpośrednio
generować IR przy użyciu API (jak w pierwszym przypadku) program
generuje tekst LLVM-owego 'assemblera', który potem jest kompilowany
narzędziami. To też jest przykład "do książki" a nie rzeczywiste
zastosowanie.

do góry

On Tue, 7 May 2013 12:49:46 +0000 (UTC), "Stachu 'Dozzie' K."
<d...@g...eat.some.screws.spammer.invalid> wrote:
> To akurat dobrze, gdy się przypomni, jak Google oberwał od Oracle za
> Javę na Androidzie. Java nie jest już platformą bezpieczną
licencyjnie.

Mnie bardziej martwil sytuacja w ktorej Google kontroluje wiecej i
wiecej technologii z ktorej korzystam...

RW

do góry

Uzytkownik "R.e.m.e.K" <g...@d...null> napisal w wiadomosci
news:5187fe0a$0$1255$65785112@news.neostrada.pl...
> Czytam o tym projekcie/technologii i mam pytanko. Otoz komplet narzedzi to
> jak wiadomo front-end zlozony z kompilatora bajtkodu, optymalizator tegoz
> bajtkodu, oraz back-end(y) ktory na wlasciwej maszynie docelowej za pomoca
> JIT generuje wlasciwy kod maszynowy. Czyli jak zgaduje dystrybucja
> aplikacji
> polega na dystrybucji bajtkodu oraz tego back-endu, ktory przy pierwszym

Genialna sprawa. O ile bylem niezbyt przekonany do wirtualnych maszyn Javy i
.NET bo ograniczaly w pewnym sensie w porównaniu z kodem wynikowym w
assemblerze, to LLVM jest uniwersalny i pozwala odciazyc twórców
kompilatórów od tworzenia kodu assemblerowego na rózne platformy wraz z
optymalizacja.

do góry

On 2013-05-17 12:22, Borneq wrote:
> Uzytkownik "R.e.m.e.K" <g...@d...null> napisal w wiadomosci
> news:5187fe0a$0$1255$65785112@news.neostrada.pl...
>> Czytam o tym projekcie/technologii i mam pytanko. Otoz komplet
>> narzedzi to
>> jak wiadomo front-end zlozony z kompilatora bajtkodu, optymalizator tegoz
>> bajtkodu, oraz back-end(y) ktory na wlasciwej maszynie docelowej za
>> pomoca
>> JIT generuje wlasciwy kod maszynowy. Czyli jak zgaduje dystrybucja
>> aplikacji
>> polega na dystrybucji bajtkodu oraz tego back-endu, ktory przy pierwszym
>
> Genialna sprawa. O ile bylem niezbyt przekonany do wirtualnych maszyn
> Javy i .NET bo ograniczaly w pewnym sensie w porównaniu z kodem
> wynikowym w assemblerze, to LLVM jest uniwersalny i pozwala odciazyc
> twórców kompilatórów od tworzenia kodu assemblerowego na rózne platformy
> wraz z optymalizacja.

No ale przeciez Java VM i LLVM to dwie rozne rzeczy. Jesli interesuje
cie implementacja JVM - zagadnienia zwiazane z optymalizacja, GC itd, to
polecam zainteresowac sie Jikes RVM http://jikesrvm.org

Standardowo dostepne sa dwie implementacje kompilatora JIT:
- "base" - bez optymalizacji - kod wynikowy ma wydajnosc zblizona do
interpretera
- "optimizing" - oparty o IR (tak, tak :-) )

Masz pomysly optymalizacyjne? Eksperymentuj :-)

--
Michal

do góry