LLVM 3.0

насолько я помню разговор был именной такой, что дескать тяжело возиться с llvm

PyPy в принципе другая вещь, чем LLVM. И да, LLVM если и подходит для динамических языков, то только с недавних пор.

Ну понятно, если пытаться реализовывать то, что не понимаешь вляпаешься со 100% вероятностью. :)

ну да. Имхо, просто не осилили. Зато много фана

Ну кто им мешал генерить не x86 асм, а для llvm

Ну кто им мешал генерить не x86 асм, а для llvm

То, что они генерят и перегенерируют асм постоянно. Насчет пригодности LLVM для Python хорошо было написано в посмертной записке Unladen.

Это же LLVM, он низкоуровневый, т.е., распараллеливанием он не занимается.

А кто запрещает FFI?

Да нет, никто не запрещает, но фанатики языка (стремящиеся заменить X на Y) не считают это Ъ :)

Байт-код НЕ оптимизируется под архитектуру. Оптимизация под конкретную архитектуру делается при компиляции байт-кода в нативный код под эту самую архитектуру.

А зачем изобретать велосипед, когда нужные библиотеки есть, и все языки имеют FFI, умеющий их вызывать? Не проще ли обернуть эту самую библиотеку в удобную и более родную для данного языка обертку вместо изобретения такой же, но нативной для данного языка, библиотеки?

Имхо, не совсем справедливая ирония, поскольку С++, написанный моими кривыми руками, уже давно по нечитабельности обогнал хаскель.

Очевидный фикс. Не надо наезжать на язык только потому, что он дает тебе слишком много свободы.

Да, а в аду С++ программисты будут разбирать ошибки STL и Boost :)

Сколько пользуюсь STL, на ошибки в нем вроде не наталкивался. Хотя, конечно, некоторые моменты сделаны не лучшим образом.

Он используется как промежуточное представление: LLVM API дает возможность генерировать только байт-код, который только потом можно скомпилить (не сохраняя байт-код на диск).

Сколько пользуюсь STL, на ошибки в нем вроде не наталкивался.

Вот, кстати, да. Правда я не так уж интенсивно пользую C++/STL, но из личного опыта - STL вполне надёжен.

Вот про Boost не скажу ни за, ни против - на практике не использовал, только немножко поковырялся по собственной инициативе.

Ошибаешься. Компиляция (любая современная) состоит из таких этапов:

1. Препроцессинг, синтаксический анализ и прочие (здесь LLVM не при чем).

2. Генерация промежуточного кода (этот и последующие пункты входят в компетенцию LLVM)

3. Оптимизация промежуточного кода.

4. (и только здесь производится оптимизация кода под архитектуру) Генерация нативного кода (она еще делится на кучу этапов, но не суть).

Такая схема не только у LLVM, а почти у всех.

А зачем изобретать велосипед

Спросите у фанатиков :)

С++, написанный моими кривыми руками

Я вообще никогда не писал на С++, но периодически приходится разбираться в чужом коде.

Вот в случае надобности такое распараллеливание должно делаться LLVM-ом при компиляции байткода в нативный код.

LLVM-код сам по себе никак не прибит к endianess.

Втянули меня в этот спор :) Вообще автоматическое запаралелливание в том виде о котором мы сейчас говорим не синоним оптимизации, оно редко кому нужно в компиляторе. Оно только увеличивает суммарное количество операций которые нужно выполнить программе. А выполнение нескольких инструкций за такт это уже стадия компиляции в native код.

Этот самый адрес сгенерирует LLVM при компиляции байт-кода в нативный код. Зачем он до этого?

С размерами и смещениями работает LLVM, а не фронтенд.

Не обязательно. Распараллеливание теоретически может происходить и на этапе оптимизации, только, дейтсвительно, поближе к трансляции в нативный код. Правда зачем оно нужно не знаю =).

Если нужно - никто не запрещает написать свой проход (LLVM Pass), только хз в каких ситуациях подобное распараллеливание даст заметный профит.

ну я о том же писал ) смысла от автоматического распараллеливания нет ) только геморрой можно нажить )

в аду С++ программисты будут разбирать ошибки STL и Boost

Ну ты и хам, так мою работу обзывать!!!

Порядок бит??? Что это???

Байт-код LLVM, к сожалению, не является платформено-независимым. Некоторые вещи LLVM определяет при формировании кода, так-то разрядность, размер int,word и т.п. Ну и Big/Litle Endian. Это вам не Java, и не C#. Кстати, информацию о том, что LLVM-байткод не может служить кросс-платформенным представлением программы для различных аппаратных платформ был в официальных доках на сабж. Байт-код сабжа собранный в Linux под x86_64 отлично компилируется/интерпретируется в Winodws под ту же аппаратную платформу, но заглохнет на ARM. Всё из-за того, что желая по максимуму использовать все особенности поддерживаемых архитектур, компилятор сабжа в баткод засовывает и дополнительную информацию. Ну а определять размер int и прочих примитивных типов данных равными стандартным для данной аппаратной архитектуры - это преступление. В Java и .NET типы данных одного размера для любой архитектуры. Поэтому у них нормальная виртуальная машина, истинно кросс-платформенная, а разрабы LLVM испортили такую идею.

Нормальный байт-код, или нечто странное от LLVM?

ну это такая штука... просто в байте биты «номеруются» с 1 до 8. А вот в слове хер знает как

В Java и .NET типы данных одного размера для любой архитектуры. Поэтому у них нормальная виртуальная машина, истинно кросс-платформенная, а разрабы LLVM испортили такую идею.

То есть размер указателя там всегда 32 бита?

Точно так же. И порядок байт в слове ничего тебе не поломает.

да кто мешает комилятору генерировать код с учетом этого? тогда будет кроссплатформенно. Это не задача llvm

как? младший арифметичски байт может как быть младшим, так и старшим по адрессу. А значит выбирать не так рпосто

[trollmode]Круто, теперь можно взять исходники любой открытой или не очень виндодиректной игры и компильнуть под линукс! Да хоть фотожоп с сонивегасом, если кто сырцы сольёт. LLVM преобразует WinApi в LinApi и дело в шляпе.[/trollmode]

Я обычно извлекаю биты так: (unsigned_number >> bit_num) & 1

Т.к. оно работает с числами, то пофиг, как эти самые байты размещены физически.

А в LLVM еще проще, т.к. там есть целые числа любой длины.

нет, там для этого тип «указатель» и методы работы с ним не зависят от его разрядности.

Т.к. оно работает с числами, то пофиг, как эти самые байты размещены физически.

ну я об это и говорил. а вот если через массив чаров тянуть

А если завести для этих целей массив чаров - тоже пофиг :) А извлекать байты из беззнакового целого (единственное, что могу вспомнить, где порядок байт все ломает) - ССЗБ.

Конечно. Сюрприз?

И да, вы не поверите, но «passing bу name» абсолютно ничего не меняет.

конечно не поверю, ибо только что с гемором на эту тему разбирался

читали эту статью, думаете она ни с того ни с сего появилась?

насолько я помню разговор был именной такой, что дескать тяжело возиться с llvm

PyPy в принципе другая вещь, чем LLVM.

конечно другая, PyPy - реализация ЯП, LLVM - backend

И да, LLVM если и подходит для динамических языков, то только с недавних пор.

это почему? и с недавних пор - это года с 2000?

Насчет пригодности LLVM для Python хорошо было написано в посмертной записке Unladen.

не было там ничего такого, чувак вещал, что он не врубается как это сделать по-человечески

PyPy - реализация ЯП

PyPy - это нечто большее.

И да, LLVM если и подходит для динамических языков, то только с недавних пор.

это почему?

Я уже сказал, где это разъясняется.

PyPy - реализация ЯП

PyPy - это нечто большее.

???? пруф или не было

И да, LLVM если и подходит для динамических языков, то только с недавних пор.

это почему?

Я уже сказал, где это разъясняется.

ссылочку не подкинешь?

http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html

просто в байте биты «номеруются» с 1 до 8. А вот в слове хер знает как

младший арифметичски байт может как быть младшим, так и старшим по адрессу. А значит выбирать не так рпосто

Ну а младший бит как был a & 1, так им и останется. Девятый бит тоже остаётся (a & 0x100) >> 8 — порядок слов на порядковых номерах битов не сказывается.

благодарствую, сейчас перечитаю

Чорт, реализации Pascal для LLVM протухшие :(

Так, значит я всё же правильно помнил основные тезисы.

Первый тезис, и самый главный: The primary reason is that we weren't able to generate enough internal customers at Google. То есть если бы не это любые вопросы можно было бы порешать.

Едем дальше, читаем про llvm.

1) «Unfortunately, LLVM in its current state is really designed as a static compiler optimizer and back end.» - не нашёл кнопку «сделать хорошо».

1) «LLVM code generation and optimization is good but expensive.» - WTF??? и что?

2) «The optimizations are all designed to work on IR generated by static C-like languages. Most of the important optimizations for optimizing Python require high-level knowledge of how the program executed on previous iterations, and LLVM didn't help us do that.» - снова не нашёл кнопку «сделать хорошо», отличная тема, чо.

3) «LLVM will not fold loads from the Python stack across calls to external functions (ie the CPython runtime, so all the time). We eventually wrote an alias analysis to solve this problem, but it's an example of what you have to do if you don't roll your own code generator.» - плачется и говорит что порулили, чего тогда плакался, снова не нашёл кнопку?

4) «For example, LLVM doesn't really support back-patching, which PyPy uses for fixing up their guard side exits. It's a fairly large dependency with high memory usage, but I would argue that based on the work Steven Noonan did for his GSOC that it could be reduced, especially considering that PyPy's memory usage had been higher.» - верните кнопку, скоты!

5) .... всё, это все претензии к LLVM?

Мой вердикт таков - чувак думал что LLVM - это страшное колдунство и если его запустить то оно автоматом все проблемы ему порешает. Ну чо, наивный малтшик, не в курсе что означают две первых L в слове LLVM.

Только я не пойму как это доказывает тезис «LLVM если и подходит для динамических языков, то только с недавних пор»? И ещё больше я не пойму, Unladden Swallow - это что, единственный динамический язык на свете, других не бывает?