Witam

Coraz wiecej czytam tu i owdzie o LLVM. Stosowana przez Apple w XCode, uzywa
jej Adobe w swoich produktach, nowe Delphi dla iOS i Androida na niej jest
oparte, jest gcc w wersji zgodnej z LLVM, nawet jadro Linuksa juz prawie w
calosci skompilowano pod LLVM a ponoc trwaja prace nad dystrybucja Debiana w
calosci pracujaca pod LLVM.
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
uruchomieniu kompiluje bajtkod. I moje pytanie: czy powstaly w wyniku
kompilacji kod jest juz niezaleznym wykonywalnym plikiem i LLVM jest mu juz
niepotrzebna czy caly czas ta LLVM siedzi w tle i bierze jakis udzial w
dzialaniu aplikacji? Skoro LLVM ma w nazwie wirtualna maszyne to wyglada
jakby byla ona potrzebna, ale na logike widze to tak jak opisalem wyzej.
Jak to jest naprawde?

--
pozdro
R.e.m.e.K

do góry

W dniu poniedziałek, 6 maja 2013 21:01:30 UTC+2 użytkownik R.e.m.e.K napisał:
> Jak to jest naprawde?

Tak na 100% to nie wiem, ale moje wyobrażenie jest takie, że to maszyna
wirtualna podejmuje decyzję o skompilowaniu jakiegoś fragmentu kodu
bajtowego do natywnego. Bez maszyny wirtualnej nie da się uruchamiać, no
chyba że kompilator całą (lub niezbędne fragmenty) MV wkompiluje w kod
natywny.

Pozdrawiam

do góry

On 2013.05.06 21:01, R.e.m.e.K wrote:

> Coraz wiecej czytam tu i owdzie o LLVM. Stosowana przez Apple w XCode, uzywa
> jej Adobe w swoich produktach, nowe Delphi dla iOS i Androida na niej jest
> oparte, jest gcc w wersji zgodnej z LLVM, nawet jadro Linuksa juz prawie w
> calosci skompilowano pod LLVM a ponoc trwaja prace nad dystrybucja Debiana w
> calosci pracujaca pod LLVM.

FreeBSD już od pewnego czasu używa clang (do budowania base systemu jak
i portów).

> 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)

Odwrotnie. Najpierw jest frontend (do c nazywa sie clang), on to
zamienia na wspólny "język" i na końcu jest backend (razem z
optymalizatorem) tworzący kod maszynowy (sytuacja taka sama jak w gcc).

> ktory na wlasciwej maszynie docelowej za pomoca
> JIT generuje wlasciwy kod maszynowy.

Jeśli mówimy o programowaniu w C lub C++ to llvm tworzy normalną binarkę
(taką jak gcc).


--
Tomek

do góry

Dnia Tue, 07 May 2013 00:35:15 +0200, Tomasz Sowa napisał(a):

>> 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)
>
> Odwrotnie. Najpierw jest frontend (do c nazywa sie clang), on to
> zamienia na wspólny "język" i na końcu jest backend (razem z
> optymalizatorem) tworzący kod maszynowy (sytuacja taka sama jak w gcc).

Tak napisalem mniej wiecej, w kazdym razie o to mi chodzilo :-)

>> ktory na wlasciwej maszynie docelowej za pomoca
>> JIT generuje wlasciwy kod maszynowy.
>
> Jeśli mówimy o programowaniu w C lub C++ to llvm tworzy normalną binarkę
> (taką jak gcc).

No ale sam jezyk jest chyba niewazny? Wszak taka jest tego idea, ze
front-end tworzy ten wspolny pseudokod, ktory juz jest identyczny (i zgodny
z jakims tam assemblerem RISCowym) dla wszystkich jezykow kompilowanych, a
dopiero wynik zalezy od back-end dla konkretnej platformy, tak?

--
pozdro
R.e.m.e.K

do góry

On 2013-05-06 21:01, R.e.m.e.K wrote:
> Witam
>
> Coraz wiecej czytam tu i owdzie o LLVM. Stosowana przez Apple w XCode, uzywa
> jej Adobe w swoich produktach, nowe Delphi dla iOS i Androida na niej jest
> oparte, jest gcc w wersji zgodnej z LLVM, nawet jadro Linuksa juz prawie w
> calosci skompilowano pod LLVM a ponoc trwaja prace nad dystrybucja Debiana w
> calosci pracujaca pod LLVM.
> 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.

Generalnie nie - LLVM to platforma do tworzenia kompilatorow. Kod
maszynowy na dana platforme nie jest generowany w czasie wykonania,
tylko kompilacji.

Jest jedno ale... Google pracuje nad technologia "Native Client". W
zalozeniach mialo to byc srodowisko bezpiecznego uruchamiania w
przegladarce _natywnego_ (x86) kodu. Tyle, ze natywny kod nie jest
przenosny, a popularnosc ARM wzrosla i pomysl z kodem x86 stal sie
niewypalem. Stad pojawil sie nowy pomysl, ze "natywny" kod bedzie od tej
pory kodem posrednim LLVM i bedzie kompilowany przez srodowisko w czasie
wykonania.
Ciekawe ile razy jeszcze Google bedzie wymyslal Jave od nowa...

--
Michal

do góry

On 2013-05-07, Michal Kleczek <m...@k...org> wrote:
[...]
> Jest jedno ale... Google pracuje nad technologia "Native Client". W
> zalozeniach mialo to byc srodowisko bezpiecznego uruchamiania w
> przegladarce _natywnego_ (x86) kodu.

To nie jest technologia, tylko środowisko, jak sam napisałeś. Kuchnia
nie jest technologią produkcji obiadu.

> Tyle, ze natywny kod nie jest
> przenosny, a popularnosc ARM wzrosla i pomysl z kodem x86 stal sie
> niewypalem. Stad pojawil sie nowy pomysl, ze "natywny" kod bedzie od tej
> pory kodem posrednim LLVM i bedzie kompilowany przez srodowisko w czasie
> wykonania.
> Ciekawe ile razy jeszcze Google bedzie wymyslal Jave od nowa...

To akurat dobrze, gdy się przypomni, jak Google oberwał od Oracle za
Javę na Androidzie. Java nie jest już platformą bezpieczną licencyjnie.

--
Secunia non olet.
Stanislaw Klekot

do góry

Dnia Tue, 07 May 2013 14:44:33 +0200 po głębokim namyśle Michal Kleczek
rzekł:

> On 2013-05-06 21:01, R.e.m.e.K wrote:
>> Witam
>>
>> Coraz wiecej czytam tu i owdzie o LLVM. Stosowana przez Apple w XCode,
>> uzywa jej Adobe w swoich produktach, nowe Delphi dla iOS i Androida na
>> niej jest oparte, jest gcc w wersji zgodnej z LLVM, nawet jadro Linuksa
>> juz prawie w calosci skompilowano pod LLVM a ponoc trwaja prace nad
>> dystrybucja Debiana w calosci pracujaca pod LLVM.
[...]
>
> Generalnie nie - LLVM to platforma do tworzenia kompilatorow. Kod
> maszynowy na dana platforme nie jest generowany w czasie wykonania,
> tylko kompilacji.
>
> Jest jedno ale... Google pracuje nad technologia "Native Client". W
> zalozeniach mialo to byc srodowisko bezpiecznego uruchamiania w
> przegladarce _natywnego_ (x86) kodu. Tyle, ze natywny kod nie jest
> przenosny, a popularnosc ARM wzrosla i pomysl z kodem x86 stal sie
> niewypalem. Stad pojawil sie nowy pomysl, ze "natywny" kod bedzie od tej
> pory kodem posrednim LLVM i bedzie kompilowany przez srodowisko w czasie
> wykonania.
> Ciekawe ile razy jeszcze Google bedzie wymyslal Jave od nowa...

Również CUDA przy kompilacji do PTX stosuje LLVM. Moje 3 grosze.

--
Edek

do góry

On 2013-05-07 14:49, Stachu 'Dozzie' K. wrote:
> On 2013-05-07, Michal Kleczek <m...@k...org> wrote:
> [...]
>> Jest jedno ale... Google pracuje nad technologia "Native Client". W
>> zalozeniach mialo to byc srodowisko bezpiecznego uruchamiania w
>> przegladarce _natywnego_ (x86) kodu.
>
> To nie jest technologia, tylko środowisko, jak sam napisałeś. Kuchnia
> nie jest technologią produkcji obiadu.

Dzieki za zwrocenie uwagi na brak precyzji.

>
>> Tyle, ze natywny kod nie jest
>> przenosny, a popularnosc ARM wzrosla i pomysl z kodem x86 stal sie
>> niewypalem. Stad pojawil sie nowy pomysl, ze "natywny" kod bedzie od tej
>> pory kodem posrednim LLVM i bedzie kompilowany przez srodowisko w czasie
>> wykonania.
>> Ciekawe ile razy jeszcze Google bedzie wymyslal Jave od nowa...
>
> To akurat dobrze, gdy się przypomni, jak Google oberwał od Oracle za
> Javę na Androidzie. Java nie jest już platformą bezpieczną licencyjnie.
>

No wlasnie chyba Google nic od Oracla w koncu nie oberwal... I od tej
pory chyba Java juz jest bezpieczna...

--
Michal

do góry

W dniu 2013-05-07 15:11, Michal Kleczek pisze:
> On 2013-05-07 14:49, Stachu 'Dozzie' K. wrote:
>> On 2013-05-07, Michal Kleczek <m...@k...org> wrote:
[...]
>>> Ciekawe ile razy jeszcze Google bedzie wymyslal Jave od nowa...
>>
>> To akurat dobrze, gdy się przypomni, jak Google oberwał od Oracle za
>> Javę na Androidzie. Java nie jest już platformą bezpieczną licencyjnie.
>>
>
> No wlasnie chyba Google nic od Oracla w koncu nie oberwal... I od tej
> pory chyba Java juz jest bezpieczna...

Gdyby nie oberwał i była bezpieczna, to aplikacje androidowe byłyby
w byte-code Javy, a nie lewą ręką do prawego ucha w imię zgodności
z licencją.

A z resztą - niech sobie wymyślają. Jeśli nie będą wymyślać, to nikt
nie wpadnie na pomysł, że coś można inaczej, może lepiej. Warto za to
zapłacić, również problemami z dużą liczbą platform.

--
Paweł Kierski
n...@p...net

do góry

On 2013-05-08 07:51, Paweł Kierski wrote:
> W dniu 2013-05-07 15:11, Michal Kleczek pisze:
>> On 2013-05-07 14:49, Stachu 'Dozzie' K. wrote:
>>> On 2013-05-07, Michal Kleczek <m...@k...org> wrote:
> [...]
>>>> Ciekawe ile razy jeszcze Google bedzie wymyslal Jave od nowa...
>>>
>>> To akurat dobrze, gdy się przypomni, jak Google oberwał od Oracle za
>>> Javę na Androidzie. Java nie jest już platformą bezpieczną licencyjnie.
>>>
>>
>> No wlasnie chyba Google nic od Oracla w koncu nie oberwal... I od tej
>> pory chyba Java juz jest bezpieczna...
>
> Gdyby nie oberwał i była bezpieczna, to aplikacje androidowe byłyby
> w byte-code Javy, a nie lewą ręką do prawego ucha w imię zgodności
> z licencją.
>

No ale przeciez Google wymyslil uzycie Dalvika _zanim_ Oracle go pozwal.
W miedzyczasie pojawilo sie OpenJDK. W tej chwili chyba nie ma juz
zadnych przeciwskazan uzycia Javy?

> A z resztą - niech sobie wymyślają. Jeśli nie będą wymyślać, to nikt
> nie wpadnie na pomysł, że coś można inaczej, może lepiej. Warto za to
> zapłacić, również problemami z dużą liczbą platform.
>

Ja tylko nie widze, co tu jest innego i lepszego.

--
Michal

do góry