После 6 месяцев разработки доступен (
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2012-May/00...
) релиз проекта LLVM 3.1 (http://llvm.org) (Low Level Virtual Machine) - GCC совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод (http://llvm.org/docs/BitCodeFormat.html) RISC подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизации). Сгенерированный платформонезависимый псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы.Основные новшества (http://llvm.org/docs/ReleaseNotes.html) LLVM 3.1:
- Представлен инструмент для автоматизированного выявления ошибок с распределением памяти AddressSanitizer, позволяющий определить факты обращения к освобождённым областям памяти, выхода за пределы границ выделенного буфера и некоторые другие типы ошибок при работе с памятью;
- Значительное улучшение поддержки стандарта C++'11 (http://www.opennet.ru/opennews/art.shtml?num=31476) в LLVM-фронтэнде Clang. В том числе добавлена поддержка лямбда-выражений, списков инициализации, атомарных операций, ключевого слова "constexpr", пользовательских литералов и т.п. Поддержка языков C, C++, Objective-C++ и Objective-C в настоящее время полностью стабилизирована для целевых плафторм x86 (32- и 64-bit) и ARM. В новой версии также добавлена расширенная поддержка литералов для Objective C и интегрирована библиотека tooling (http://clang.llvm.org/docs/Tooling.html) для упрощения разработки собственных инструментариев на базе Clang;- В генератор кода добавлена поддержка "связок инструкций" (instruction bundles (http://llvm.org/releases/3.1/docs/CodeGenerator.html#machine... позволяющих смоделировать поддержку VLIW-групп через упаковку произвольного числа параллельных инструкций. В итоге, значительно улучшена поддержка генерации кода для целевых архитектур процессоров VLIW (http://ru.wikipedia.org/wiki/VLIW) (например, применяется в некоторых GPU), в которых одна инструкция содержит несколько параллельно выполняющихся операций. Кроме того, в генератор кода добавлена поддержка алгоритма "Basic Block Placement", поддерживающий вероятностные методы размещения блоков кода;
- Добавлена (http://llvm.org/releases/3.1/docs/ReleaseNotes.html#arminteg... реализация интегрированного макро-ассемблера для архитектуры ARM, который ускорил время компиляции и дал возможность реализовать некоторые дополнительные возможности для целевых систем ARM, такие как Thumb1, Thumb2 и ARM режимы, а также поддержку специфичных расширений для VFP2, VFP3 и NEON;
- Значительное улучшение работы MIPS-бэкенда, теперь полноценно поддерживающего архитектуру MIPS64;
- Добавлен новый порт с поддержкой процессоров Qualcomm Hexagon VLIW;
- В DragonEgg, плагине к набору компиляторов GCC, заменяющем оригинальные оптимизаторы и генераторы кода GCC на аналоги, созданные в рамках проекта LLVM, в дополнение к полной поддержке работы в виде плагина к GCC 4.5 и 4.6 без применения дополнительных патчей, добавлена базовая поддержка GCC 4.7. Также добавлена возможность сборки для архитектуры ARM;
- Улучшена работа библиотек libc++ (http://libcxx.llvm.org/) и compiler_rt (http://compiler-rt.llvm.org/), которые распространяются под двойной лицензией MIT и UIUC. Библиотека libc++ представляет собой (http://www.opennet.ru/opennews/art.shtml?num=26560) реализацию стандартной библиотеки классов C++, распространяемую под BSD-подобной лицензией и нацеленную на высокоэффективную генерацию кода и на максимальное обеспечение совместимости с существующими и будущими стандартами. Библиотека обеспечивает минимальное потребление памяти, высокую скорость выполнения функций, быструю компиляцию и совместимость на уровне ABI с libstdc++ из состава GCC для некоторых низкоуровневых возможностей, таких как объекты-исключения (exception objects), rtti и распределение памяти. В настоящее время libc++ уже интегрирована в базовую систему FreeBSD и планируется к использованию по умолчанию в FreeBSD 10. Отмечается также портирование libc++ для Solaris и возможность полноценного использования на данной платформе в сочетании с libcxxrt и clang;
- Значительное увеличение производительности проекта VMKit (http://vmkit.llvm.org/), виртуальной машины Java VM, использующей LLVM для статической и JIT-компиляции;
- В число официально поддерживаемых проектов включён экспериментальный оптимизатор Polly (http://polly.llvm.org/), в настоящий момент поддерживающий несколько техник оптимизации циклов и позволяющий организовать автоматическое распараллеливание кода с задействованием OpenMP. Для использования polly в clang следует указать "-O3 -mllvm -polly";
- Для целевых платформ X86-32 и X86-64 значительно расширена поддержка набора инструкций AVX 2 (Advanced Vector Extensions), устранены проблемы с ранее реализованной поддержкой AVX1, добавлена поддержка расширений FMA4 и XOP;
- Добавлены официально поддерживаемые биндинги для языка Python, которые пока поддерживают только интерфейс для работы с объектными файлами и дизасемблер;
- Добавлена утилита llvm-stress для проведения стресс-тестирования различных компонентов LLVM путем генерации случайных ll-файлов.
Из параллельно развивающихся проектов, основанных на LLVM, можно отметить:
- KLEE (http://klee.llvm.org/) - символьный анализатор и генератор тестовых наборов;- Runtime-библиотека compiler-rt (http://compiler-rt.llvm.org/);
- llvm-mc (http://llvm.org/releases/2.6/docs/ReleaseNotes.html#mc) - автогенератор ассемблера, дизассемблера и других, связанных с машинным кодом компонентов, на основе описаний параметров LLVM-совместимых платформ.
- VMKit (http://vmkit.llvm.org/) - виртуальная машина для Java и .NET;
- Реализация функционального языка программирования Pure (http://pure-lang.googlecode.com/);
- LDC (http://www.dsource.org/projects/ldc) - компилятор для языка D;
- Roadsend PHP (http://code.roadsend.com/rphp) - оптимизатор, статический и JIT компилятор для языка PHP;
- Виртуальные машины для Ruby: Rubinius (http://rubini.us/) и MacRuby (http://www.macruby.org/);
- Unladen
Swallow (http://code.google.com/p/unladen-swallow/) - реализация языка Python;- LLVM-Lua (http://code.google.com/p/llvm-lua/)
- FlashCCompiler (http://llvm.org/devmtg/2008-08/Petersen_FlashCCompiler.pdf) - средство для компиляции кода на языке Си в вид пригодный для выполнения в виртуальной машине Adobe Flash;
- LLDB (http://lldb.llvm.org/) - новая (http://www.opennet.ru/opennews/art.shtml?num=26907) модульная инфраструктура отладки, использующая такие подсистемы LLVM как API для дизассемблирования, Clang AST (Abstract Syntax Tree), парсер выражений, генератор кода и JIT-компилятор. LLDB поддерживает отладку многопоточных программ на языках C, Objective-C и C++; отличается возможностью подключения плагинов и скриптов на языке Python; демонстрирует экстремально высокое быстродействие при отладке программ большого размера;
- emscripten (https://github.com/kripken/emscripten/wiki) - компилятор биткода LLVM в JavaScript, позволяющий преобразовать для запуска в браузере приложения, изначально написанные на языке Си. Например, удалось запустить Python, Lua, Quake, Freetype;
- sparse-llvm (https://github.com/penberg/sparse-llvm) - бэкенд, нацеленный (http://www.opennet.ru/opennews/art.shtml?num=31636) на создание Си-компилятора, способного собирать ядро Linux.
- Portable OpenCL (http://www.opennet.ru/opennews/art.shtml?num=32092) - открытая и независимая реализация стандарта OpenCL;
- CUDA Compiler (http://www.opennet.ru/opennews/art.shtml?num=33800) - позволяет сгенерировать GPU-инструкции из кода, написанного на языках Си, Си++ и Fortran;
- Julia (http://www.opennet.ru/opennews/art.shtml?num=33315) - открытый динамический язык программирования, использующий наработки проекта LLVM.
URL: http://lists.cs.uiuc.edu/pipermail/llvm-announce/2012-May/00...
Новость: http://www.opennet.ru/opennews/art.shtml?num=33915
Polly вкусная няшка.
хм понять бы как её в генте завести..
Если бы LLDB был не только под Apple.
> Если бы LLDB был не только под Apple.Что Вы имеете в виду? Насколько написано в документации, он должен работать под Linux. Я собирал и запускал его (правда, сильно поизучать его не удалось из-за нехватки времени...)
Вот другие обещают, но не делают, а LLDB, значит, может больше, чем на главной странице:
"LLDB is known to work on the following platforms, but ports to new platforms are welcome:
Mac OS X desktop user space debugging for i386 and x86-64
iOS simulator debugging on i386
iOS device debugging on ARM"
Да, на главной действительно нету. Но есть вот это: http://lldb.llvm.org/build.html ("Building LLDB on Linux")
"Параллельно развивающийся" проект Unladen Swallow умер 2 года назад "за ненадобностью". Где он развивается?
> Где он развивается?В параллельной вселенной, разумеется. Никогда не слышали про кота Шредингера и ансамбли миров чтоли? :)
clang static checker классная штука, жаль только для C, а не C++
Я им нашел ошибки в нескольких opensource проектах
Объясните, что такое LLVM? Это наподобие Java? Скомпилировал в байт-код и могу использовать на разных платформах с LLVM. Или это наподобия виртуальной явы машины, а clang типа jcc. Вот для примера у меня есть какой либо код написанный с использованием C++(никакого гуи только консоль). Каким образом компилировать? llvm или clang?
Первое предложение c llvm.org:"The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Despite its name, LLVM has little to do with traditional virtual machines, though it does provide helpful libraries that can be used to build them."
LLVM это набор библиотек для создания компиляторов, основная библиотека предоставляет универсальный бэкенд. Clang - С/C++ компилятор использующий LLVM.
> Первое предложение c llvm.org:
> "The LLVM Project is a collection of modular and reusable compiler and
> toolchain technologies. Despite its name, LLVM has little to do with
> traditional virtual machines, though it does provide helpful libraries that can
> be used to build them."
> LLVM это набор библиотек для создания компиляторов, основная библиотека предоставляет
> универсальный бэкенд. Clang - С/C++ компилятор использующий LLVM.Т.е. LLVM это просто библиотеки? И clang не обязательно использовать LLVM?
Clang это компилятор построенный на технологиях LLVM. Для тебя это будет такой же компилятор как и GCC, только с более быстрой компиляцией и лучшими средствами диагностики.
> Clang это компилятор построенный на технологиях LLVM. Для тебя это будет такой
> же компилятор как и GCC, только с более быстрой компиляцией и
> лучшими средствами диагностики.Т.о. кроссплатформеность LLVM это кроссплатформенность Clang. И чтобы какое либо приложение было много платформенным необходимо компилировать clang-ом в разных ОС? Или достаточно из одной ОС компилировать с разными флагами под системы? Я все правильно понял?
> И чтобы какое либо приложение было много платформенным необходимо компилировать clang-ом в разных ОС?Чтобы какое либо приложение было кроссплатформенным, его нужно таким НАПИСАТЬ. А компилировать его можно тем, что вы выбрали для каждой отдельной платформы
Ну так и в чем суть LLVM? Virtual machine не?
>> Clang это компилятор построенный на технологиях LLVM. Для тебя это будет такой
>> же компилятор как и GCC, только с более быстрой компиляцией и
>> лучшими средствами диагностики.
> Т.о. кроссплатформеность LLVM это кроссплатформенность Clang. И чтобы какое либо приложение
> было много платформенным необходимо компилировать clang-ом в разных ОС? Или достаточно
> из одной ОС компилировать с разными флагами под системы? Я все
> правильно понял?тыц вся плюшность что кланг(и тысячи своих компиляторов) можно писать только для ллвм а уже ллвм портировать на новые платформы. и с очевидными огранчениями кланг автоматически зарабоатет на новой архитектуре.
> же компилятор как и GCC, только с более быстрой компиляцией и лучшими средствами диагностики.А также:
- С кривым оптимизатором, выдающим код хуже укуренной обезьяны под градусом. Порой еще и неверный код к тому же генерится.
- Вагоном странных багов, когда все падает к черту с internal error. Так что вместо написания программы вы идете воркэраундить чужой баг компилера...
- Странные баги в кодогенерации. Хотите ощутить что ваша программа живет своей жизнью и насколько кайфово ловить неочевидные левые глюки в которых вы не виноваты? Добро пожаловать в программерский ад.
- Поддержкой полутора архитектур и систем. Реально почти все разработчики вкалывают в эппле, их интересует 1-2 архитектуры и по сути 1 единственная система в паре вариантов. На все остальное эпплу по очевидным причинам положить. Поэтому доводить до ума вы их будете как-то сами. Почему вы? Потому что яблоку не надо а других как-то и нет.
Есть подозрение, что Вы не полностью правы насчет его стабильности и того, кому он интересен. Например:
* FreeBSD 10 отказывается от GCC в пользу CLANG: http://www.linux.org.ru/news/bsd/7747515
* Debian экспериментирует с этим вопросом: http://www.opennet.ru/opennews/art.shtml?num=33281Хотя я не отрицаю, стабильность пока оставляет желать лучшего - internal error'ы мне попадались самому, к сожалению.
> internal error'ы мне попадались самому, к сожалению.Справедливости ради хочу отметить, что речь шла про версию 3.0. Что касается 3.1 - она только что полностью собрала наш проект, на котором падала ее предшественица.
> * FreeBSD 10 отказывается от GCC в пользу CLANG:А эти господа велосипедисты-концептуалы на проблемы своих пользователей по жизни чихать хотели. В ответ все больше контор чихает уже на них. В том числе и потому что выбор между некрофильской версией gcc и глючным шлангом - по вкусу далеко не всем.
> * Debian экспериментирует с этим вопросом:Они и с hurd экспериментируют. Давайте вы свалите на debian/GNU hurd?
> internal error'ы мне попадались самому, к сожалению.
Ну так эппл чужие проблемы чинить не будет.
>> * FreeBSD 10 отказывается от GCC в пользу CLANG:
> А эти господа велосипедисты-концептуалы на проблемы своих пользователей по жизни чихать
> хотели. В ответ все больше контор чихает уже на них. В
> том числе и потому что выбор между некрофильской версией gcc и
> глючным шлангом - по вкусу далеко не всем.
>> * Debian экспериментирует с этим вопросом:
> Они и с hurd экспериментируют. Давайте вы свалите на debian/GNU hurd?
>> internal error'ы мне попадались самому, к сожалению.
> Ну так эппл чужие проблемы чинить не будет.внимание вопрос товарищи знатоки где в новости о выходе нового кланга и ллвм содержится неотложный приказ тебе юзеру да-да именно тебе в третьем ряду с красными глазами, да и впрочем вам остальным использовать его?
кевин, жжешь! :)
Мы вроде как находимся на форуме посвященному OpenSource - добро пожаловать! Какой открытый проект не глючный скажи мне пожалуйста? Особенно на ранней стадии своего развития. GCC до 4 версии насколько я знаю был тоже далеко не сахар. Я clang'ом не пользовался, а только LDC - впечатления очень положительные. Если есть проблемы, то в лучших традициях опенсорса тебе сюда http://llvm.org/bugs/
Кхм. LDC вместо DMD? Но зачем...
Ну dmd мой основной компилятор, но и ldc пользоваться иногда приходится. На линуксе работает практически также, компилирует медленнее, зато генерируемый код быстрее.
> Ну dmd мой основной компилятор,Мсье знает толк...
> Если есть проблемы, то в лучших традициях опенсорса тебе сюда http://llvm.org/bugs/Глупо ломиться в запертую дверь если она стоит в чистом поле. Можно просто взять и обойти. Внезапно: GCC не падает, генерит код под кучу платформ (вот прям ща бинарь под Atmel AVR мне билданул, например). При компилежке ничего не падает. И код генерится такой что закачаешься: на easyelectronics например показано как перец приделал к avr'кам си++ классы для дергания лапками. GCC в ответ отжог и выдал феноменальную по простоте и эффективности конструкцию, невзирая на концепции. Буквально считанные асмовые команды. Вот это то что я называю фразой "хорошо работающий оптимизатор". Я бы даже сказал, круто работающий - никогда б не подумал что это можно так компактно утрамбовать. Это конечно изврат, но оптимизатору - зачет.
Понимаешь, мне не @#$тись с концептуальным тулом надо, который может быть, когда-то там. А чтоб оно работало. Желательно прям ща и хорошо. Свою ненависть к GPL и подхалимаж к эпплу засунь уже туда где не светит солнце. С таким подходом далеко не уедешь. Особенно если надо бинарник который меряет датчики и щелкает нагрузкой по нужному алгоритму вот прям ща, а не через 10 лет. И да, я не вижу в каком месте меня обули на права. Этот блоб по сути 100% проприетарь. У тебя его никогда не будет. Да и не нужен он тебе, это единичная штука "по месту, по ситуации". И я не вижу в каком месте и чья лицензия была попрана: там кроме моего кода вообще нихрена нет. А тот кто просто генерил код - никаких правов по этому поводу вообще не приобретает ;]
Че сказать-то хотел.. Залогинься уже, User. Ты можешь изменить ник, но стиль вполне узнаваем.
Первый абзац вроде ничего. Но потом эталонный неадекват :(
не говори мне, чем пользоваться и не скажу куда тебе следует пойти.
не нравится - не ешь, только молча, не нужно всем остальным рассказывать как это не вкусно, если у всех остальных оно за обе щеки уплетается.
>[оверквотинг удален]
> - Вагоном странных багов, когда все падает к черту с internal error.
> Так что вместо написания программы вы идете воркэраундить чужой баг компилера...
> - Странные баги в кодогенерации. Хотите ощутить что ваша программа живет своей
> жизнью и насколько кайфово ловить неочевидные левые глюки в которых вы
> не виноваты? Добро пожаловать в программерский ад.
> - Поддержкой полутора архитектур и систем. Реально почти все разработчики вкалывают в
> эппле, их интересует 1-2 архитектуры и по сути 1 единственная система
> в паре вариантов. На все остальное эпплу по очевидным причинам положить.
> Поэтому доводить до ума вы их будете как-то сами. Почему вы?
> Потому что яблоку не надо а других как-то и нет.весь мой генту перекомпилировался клангом(за исключением 5 приложений где было лень копать) и работает замечательно
ну и проблемы там токо на си коде, всё на плюсах без проблем( опенмп отключил да -_-)
> ... Это наподобие Java? Скомпилировал в байт-код и могу использовать на разных платформах с LLVM. Или это наподобия виртуальной явы машины, а clang типа jcc.Эксперименты с переносимым байт кодом LLVM идут в NativeClient-е, без особого успеха.
А так - либа, которая генерит машинный код, местами кое-как.
Это скорее и то и другое. CLANG - это фронтенд компилятор. Который разбирает синтаксис C/C++ и генеряет из него байткод наподобие RISK архитектуры. LLVM - виртуальная машина, которая может этот байткод исполнять, генерять нативный код на выбранной системе, упрощает создание различного рода инструментов анализа кода.. Такое разделение так же позволяет вносить более суровые оптимизации в LLVM не трогая собсно синтаксический анализатор.
C Java в этом отношении очень много общего. Хотя и там эта идея была не нова. В Java позаимствовали наработки Вирта(если не ошибаюсь Модула3/Оберон) и промежуточное представление если не полностью, то во многом унаследовано от P-кода равно как и во многих других языках.
"Идея p-кода принадлежит Арсу Эмману (Urs Ammann), студенту Никлауса Вирта. В своем документе «On Code Generation in a Pascal», опубликованном в 1977 году, Эмман описал метод трансляции исходного кода программы в промежуточный код и то, как эта идея может быть использована для создания переносимых программ. Год спустя Кэн Боулс (Ken Bowles), профессор Калифорнийского университета в Сан Диего, разработал операционную систему UCSD p-System, в основе которой лежала виртуальная машина, исполняющая p-код, который, в свою очередь, создавался специальным компилятором с языка Pascal.Идеей p-кода также заинтересовался и сам Никлаус Вирт. В 1985 году он начал работу над операционной системой Oberon, которая базировалась на интерпретаторе p-кода и высокоуровневом языке Oberon. Позднее на ее основе была создана ОС BlueBottle, развитие которой продолжается по сей день."
Значит, хотя бы это уже не смогли запатентовать корпорации. И то славно...
> Значит, хотя бы это уже не смогли запатентовать корпорации. И то славно…как будто наличие prior work мешает выдаче патента. патентные бюро патенты не проверяют, фактически. и если сформулировать заявку достаточно туманно или «другими словами» — можно стричь купоны. потому что судебные разбирательства — штука дорогая, бизнес в это время стоит колом и вообще неудобно.
>clang static checker классная штука, жаль только для C, а не C++Ты про статический анализатор? Если да, то он есть и под C++
Отличный проект. Благодаря LLVM появилась возможность экспериментировать с новыми языками программирования компилирующими в нативный код, не углубляясь в детали кодогенерации. До этого это было невозможно, не связываясь с ужасом под названием GCC.
> Отличный проект. Благодаря LLVM появилась возможность экспериментировать с новыми языками
> программирования компилирующими в нативный код, не углубляясь в детали кодогенерации.
> До этого это было невозможно, не связываясь с ужасом под названием
> GCC.LLVM как раз-таки позволяет углубляться в детали кодогенерации в отличие от "ужаса под названием GCC".
>> Отличный проект. Благодаря LLVM появилась возможность экспериментировать с новыми языками
>> программирования компилирующими в нативный код, не углубляясь в детали кодогенерации.
>> До этого это было невозможно, не связываясь с ужасом под названием
>> GCC.
> LLVM как раз-таки позволяет углубляться в детали кодогенерации в отличие от "ужаса
> под названием GCC".Нет. LLVM IR довольно-таки high-level штука. Совсем необязательно знать даже ассемблер чтобы написать кодогенератор для своего языка с помощью llvm.
> Совсем необязательно знать даже ассемблер чтобы написать кодогенератор для своего языка с помощью llvm.И работать он будет как кодогенератор, сделанный человеком, который даже не знает ассемблер.
>> Совсем необязательно знать даже ассемблер чтобы написать кодогенератор для своего языка с помощью llvm.
> И работать он будет как кодогенератор, сделанный человеком, который даже не знает
> ассемблер.Он работает как кодогенератор, который сделан людьми, которые знают ассемблер. А вот чтобы пользоваться им - это необязательно. Он лишь абстрагирует бэкенд от фронтенда. Все-таки не будем голословными, пока лишь были слезы про то что все плохо, но конкретных примеров никто так и не привел.
> что все плохо, но конкретных примеров никто так и не привел.А тебе что, слабо погуглить по наиболее типовым ошибкам и найти тонну мата самому? Ничо, ща бсдельники на него переползут - вот тут то и обчитаешься :)
>> что все плохо, но конкретных примеров никто так и не привел.
> А тебе что, слабо погуглить по наиболее типовым ошибкам и найти тонну
> мата самому? Ничо, ща бсдельники на него переползут - вот тут
> то и обчитаешься :)наиболее типовая ошибка в том что многие пробуя кланг пропускают предупреждения стреляют себе в колено а потом плачуться на форумах..
> До этого это было невозможно, не связываясь с ужасом под названием
> GCC.До этого делали генератор С кода, который компилили через любой С-компилятор. Удобство: можно использовать _любой_ С-компилятор и получить качественный код на выходе. Недостаток: дольше компилится (т.е. например, для JIT не совсем удобно).
LLVM/Clang 3.1 доступен в составе базовой системы FreeBSD 9-STABLE.
Фряха поддерживает арм? Если да, то странно смотреть на их спешки, сланг много каки генерит для арма. К примеру вместо инструкции bl(переход с возвратом) втыкает 2 инструкции
mov lr, pc (сохраняет адрес возврата)
b (и переходит)bl делает тоже самое за одну инструкцию. Потом много чего компилится криво, например faad после компиляции шлангом выдает приколымые звуки почти похожие на оригинал.
> например faad после компиляции шлангом выдает приколымые звуки почти похожие на оригинал.Можно реализовать большой проект быстро, дешево и качественно. Но в любой момент времени вы можете выбрать только любые 2 из этих 3 свойств.
> Фряха поддерживает арм?Давно уже. Правда в качестве экспериментальной архитектуры, так как до конца не определены механизмы получения информации о периферийных устройствах сынтегрированных с ядром arm.
> Потом много чего компилится криво, например faad после компиляции шлангом выдает приколымые звуки почти похожие на оригинал.
А может дело в консерватории (в режиме кодирования), который не поддерживается faad?
(Собрал faad2-2.7 из порта с помощью системного LLVM/Clang 3.0 и 3.1 — артефактов в воспроизведении M4A-файлов, созданных с помощью faac, не заметил).
На арме собрал?
> (Собрал faad2-2.7 из порта с помощью системного LLVM/Clang 3.0 и 3.1 —И что за ARMовская машинка была? А то как бы названия команд типа b и bl должны бы навести на смутные подозрения что это слегонца не х86 был :)
>> (Собрал faad2-2.7 из порта с помощью системного LLVM/Clang 3.0 и 3.1 —
> И что за ARMовская машинка была? А то как бы названия команд
> типа b и bl должны бы навести на смутные подозрения что
> это слегонца не х86 был :)faac/faad2 собирал под [amd64]. Вопрос был о качестве компиляции декодера.
> faac/faad2 собирал под [amd64]. Вопрос был о качестве компиляции декодера.вопрос, наш недалёкий друг, был о качестве кодогенератора под ARM. но ты у нас не читатель, ты писатель прозаек.
Походу это интересно *bsd юзерам по большей степени.Использую джава, ибо это супер мега крутая весчь по до всё и вся, для с++ юзаю g++.
> Использую джавану и шёл бы себе мимо.
>> Использую джава
> ну и шёл бы себе мимо.Очень продуктивный коммент =)
>>> Использую джава
>> ну и шёл бы себе мимо.
> Очень продуктивный коммент =)примерно как твой. мы спать не могли, мечтали увидеть восхваление жабы в теме про llvm. а также очень хотели узнать, что именно ты именно жабу любишь и используешь.
А вот Вы как любите свою жабу? Давайте рассказывайте, не стесняйтесь.
и действительно
Джава в теме LLVM - означает пользуешься VMKit??
а ну поделись успехами!