Dnia Thu, 09 May 2013 12:59:20 +0100 po głębokim namyśle Andrzej Jarzabek
rzekł:

> On 08/05/2013 22:15, Edek wrote:
>> Dnia Wed, 08 May 2013 21:18:15 +0100 po głębokim namyśle Andrzej
>> Jarzabek rzekł:
>>
>> 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.
>
> 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. Ja od zawsze, tak mnie
nauczono, myślę w wartwach abstrakcji tam gdzie je się stosuje,
i dla mnie LLVM zapewnia abstrakcyjną VM, niezależnie od implementacji,
która tradycyjną VM nie jest.

>>> Z innych rzeczy - na pewno jest to interesująca propozycja dla kogoś,
>>> kto chce tworzyć DSL-e wykonujące się z dobrą wydajnością (czyli
>>> kompilowane). Jakiś czas temu w takim zastosowaniu Roman W pisał o
>>> projekcie gdzie taki język był osadzony w Haskellu, co na pewno ma
>>> swoje zalety, ale też i wady. LLVM daje (czy zdaje się dawać) rozsądną
>>> alternatywę implementowania samodzielnego DSL-a zamiast osadzania.
>>
>> Czyli jak konkretnie?
>
> 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ł.

--
Edek