Чтобы добавлять сообщения и комментарии, .

@Shchvova:
Shchvova

.

@Strephil:
Strephil

Прекращена поддержка Windows Vista и XP. Для работы LLVM на платформе Windows требуется Windows 7 и старше.

@OCTAGRAM:
OCTAGRAM

Я как–то проводил инвентаризацию, как бы теоретически можно было писать под Cocoa для Windows:
1. Реализация Cocoa берётся из iTunesInstaller.exe
2. Компилятор либо LLVM, либо LLVM в роли ObjC => C транслятора, затем другим транслятором
3. Оставались только заголовочные файлы, которые, наверное, надо брать из XCode, вот только какой версии, не очень было понятно. Учитывая, как реализована совместимость на уровне машинных кодов в Objective-C, в принципе, можно брать самую новую и просто не использовать слишком новые методы.
Нашёл время провести более детальный анализ того, что же именно содержит Apple Application Support. Во–первых, собственно Objective-C портированных библиотеки там 2: Foundation.dll и CoreFoundation.dll. В закрытых версиях Apple есть несколько типов CoreFoundation, которые без конвертации можно привести к указателю на Objective-C (toll-free bridging). Похоже, что это оно. Если поставить iCloud, там ещё можно отрыть AOSKit.dll, экспортирующий какие–то Objective-C классы. Никаких AppKit нет.
Что касается версии, я немного позанимался дихотомией и пришёл к выводу, что Apple Application Support из iTunes примерно соответствует версиям Lion/Mountain Leopard. Если скачать с сайта ADC xcode462_cltools_10_76938260a.dmg, он же Command Line Tools (OS X Lion) for Xcode — April 2013.dmg, достать оттуда 7-zip'ом Foundation.h и взять этот же файл из command_line_tools_for_osx_mountain_lion_april_2014.dmg, то видно, что, например, добавился #import <Foundation/NSHashTable.h>, и я вижу OBJC_CLASS_$_NSHashTable в Foundation.dll, и для некоторых других новых классов тоже, но не всех. А из Maverick (commandlinetoolsosx10.9forxcode6.2.dmg) я ничего добавленного уже не вижу.
Все остальные библиотеки реализованы более менее без Objective-C. Несколько библиотек, вижу, импортируют несколько вызовов objc.dll, но, похоже, только лишь для того, чтобы поработать с blocks и libdispatch.dll.
Таким образом, реально из iTunes можно взять:
1. Коллекции и связанные с ними Property List сериализаторы
2. Quartz (CoreGraphics), которым, в частности, можно рисовать текст нормально, как на Mac OS X, без радужного замыливания
3. «Официальный» порт libdispatch
Может, ещё какие не–Objective-C библиотеки, коих там куча.
AppKit, видимо, только через GNUStep, Cocotron или YellowBox. Свои интерфейсы Safari и iTunes, видимо, как–то через C'шные библиотеки отрисовывают поверх C'шного Quartz.

В отсутствие AppKit самое интересное (для меня) остаётся в libdispatch. И libdispatch, и libuv решают похожие задачи, но кто из них лучше? У libdispatch на Windows, кроме «официального» порта есть два неофициальных, и неплохо бы было, чтобы кто–нибудь посравнивал их между собой на предмет проблемы C10k.

@Zert:
Zert

Итак, 20 мегабайт ll-кода компилилось 1 час 20 минут примерно. Не знаю, нормально это или нет.

@Zert:
Zert

Сгенерилось 20 мегабайт ll-кода. Интересно, сколько компилиться будет…

@Zert:
Zert

А ядро ещё шлангом не собирается? Есть ли какие-то подвижки в эту сторону?

@OCTAGRAM:
OCTAGRAM

parasail-programming-language.blogspot.ru
С июля давно новостей не было, я уж думал, после слияния с AdaCore проект утонул. Как–никак, исследовательский. Ан нет, работа продолжается. С виртуальной машины переносят на нативный компилятор на базе LLVM.
Проект пока ещё не зрелый. Я пытался применить вместо node.js+Wind.js, но сразу наткнулся на то, что нет зелёнопоточной сети и работы с XML, а самому делать некогда было.

@arrowdodger:
arrowdodger

Офигеть, Common Lisp на LLVM: drmeister.wordpress.com

@JCD:
JCD

habrahabr.ru

@anton0xf:
anton0xf

бгг: LLVM: Implementing a Language
чего только не найдешь в интернете. надо будет полистать.

@Zert:
Zert

Development of a Translator from LLVM to ACL2 arxiv.org
Это вин, ящитаю.

@O01eg:
O01eg

А вот если использовать генерящий платформонезависимый код модифицированный clang из pNaCl и сделать к нему фреймворк из EFL, можно ж запилить совсем свободную альтернативу JVM и CLR.

@lexszero:
lexszero

А почему еще никто не запилил транслятор для QEMU, жрущий нормальный человеческий IR-код? Все лепят какие-то велосипеды из костылей, то жаву на голом виртуальном калькуляторе-переростке с тьюринг-полным MMU пускают, то еще что.

@Zert:
Zert

opennet.ru

Фанатикопроблемы. У Столлмана «свобода пользователя» — это то же самое, что и у Путина. Пользователь должен жить в будке и жрать похлёбку из селёдочных голов.

@ndtimofeev:
ndtimofeev

А есть где-нибудь документация по API предоставляемым clang'ом?

@4DA:
4DA

VMKit: a substrate for virtual machines
vmkit.llvm.org

@13oz:
13oz

есть где-нибудь информация о том, как работает сабж, на русском?

@hizel:
hizel

свежерелизнувшийся llvm перешл на sphinx. копыто-пожму!

@hizel:
hizel

andrewkelley.me

@arrowdodger:
arrowdodger

Qt, скомпиленный в джаваскрипт работает в браузере: badassjs.com
Блин, как эта байда работает? Во что превращаются вызовы если не ядра, то хотя бы иксов?

@arrowdodger:
arrowdodger

Собрал фаерфокс с libc++ в качестве стандартной либы и со стандартом C++11, а он собрался и работает. Вин.

@arrowdodger:
arrowdodger

Кланг к успеху идет.
Embarcadero C++ Builder XE3 released: Highly-conforming Clang-based C++11 compiler

@arrowdodger:
arrowdodger

А кланге пилят модули для С/С++. Всмысле, вместо хедеров будут модули.

@helgi:
helgi

llvm.org — LLVM превосходит ожидания.

@trapdoor:
trapdoor

Посмотрела Лёню ускорение язычков с LLVM: skillsmatter.com

И тут, внезапно, бенчмарк: shallow 1.6, deep 16, llvm 17+, c 0.2.

А в чём профит тогда?..

@Kibab:
Kibab

"All these things would be impossible, if we would be doing them with GCC... Well, not impossible... But I wouldn't be smiling :)" (c) Jonathan Anderson о пользе LLVM в исследовательских проектах университета Cambridge

@Equidamoid:
Equidamoid

Попробовал автокомплит на основе clang. Fail. Куча ругани на "no member named $type in global namespace" и нифига не работает.
Хотя мб код под андроидовский NDK — это слишком для него?..

@arrowdodger:
arrowdodger

О, Intel запилили поддержку профилирования JIT'нутого кода для ихнего Intel Parallel Amplifier XE (VTune). Параллельно с этим отрефакторили поддержку OProfile.

@arrowdodger:
arrowdodger

Прикольно, KLEE сумела обратить две CRC32 операции за полчаса.

@arrowdodger:
arrowdodger

Кстати, эти кадры сделали забавную штуку — на винде ихний MCJIT тоже работает, несмотря на то, что они эмитят ELF.
Т.е. на выходе получается ELF контейнер, содержащий виндовый код (вызовы Windows API, например) и эта байда работает.

@arrowdodger:
arrowdodger

Ну вот, Intel запилила MC-JIT (JIT, использующий новый фреймворк MC для работы с машинным кодом) для ELF. Апстримят патчи теперь.
Говорят, запилили отладку JIT-кода из GDB.

@arrowdodger:
arrowdodger

AMD заопенсурсили AMDIL бэкэнд к LLVM. Он, правда, для 2.9, но они обещают в скором времени допилить его до транка и закоммитить в репозиторий.
Другая проблема — "LLVM-IR that isn’t generated from AMD’s OpenCL frontend does not produce any AMDIL". Не уверен точно почему.

@arrowdodger:
arrowdodger

Грязный хак сработал.
This is a triumph. I'm making a note here — HUGE SUCCESS.

@arrowdodger:
arrowdodger

Ну вот, libc++ и libcxxrt закоммичены в HEAD ветку фряхи. Сейчас, правда, они ни для чего не юзаются и билдятся только при наличии специального кноба.
Автор подумывает о перепиле базового GCC, чтобы он юзал libcxxrt вместо GNU'шной libsupc++. Это в будущем позволит избежать проблем с ABI при переходе на новую стандартную библиотеку С++.
Олсо, в десятой фряхе планируется выпилить как GCC, так и его libstdc++.

@arrowdodger:
arrowdodger

Ну и магия эти компиляторы.
Мужик разработал мудреную оптимизацию (патч на 92кб), прогнал тесты, везде прирост производительности, кроме одного теста. Сидят теперь в рассылке, рассуждают отчего. Вольный перевод:
"В проблемном базовом блоке есть независимые loads и stores. Aliasing
analysis позволяет выявить, что они не относятся к одной и той же области памяти.
Однако, некоторые расчет смещений, используемых в этих loads и stores
оптимизируются векторизатором (оптимизацией, разработанной мужиком).
Когда эта фигня случается aliasing analysis теряет возможность доказать, что
эти доступы к памяти независимы и происходят КРОВЬКИШКИ."

Ну скажите, не магия ли?

@arrowdodger:
arrowdodger

// In newer versions of STP, a memory management mechanism has been
// introduced that automatically invalidates certain C interface
// pointers at vc_Destroy time.

FUUUUUUUUU~, я дебажил это два часа, пока не прочитал коммент.

@arrowdodger:
arrowdodger

В транк закоммитили первый патч проекта Address Sanitizer. Это что-то вроде -fstack-protector, только какой-то продвинутый. На очереди рантайм и патч для кланга.

@arrowdodger:
arrowdodger

bool rewriteInstructionForSpills(const LiveInterval &li, const VNInfo *VNI, bool TrySplit, SlotIndex index, SlotIndex end, MachineInstr *MI, MachineInstr *OrigDefMI, MachineInstr DefMI, unsigned Slot, int LdSlot, bool isLoad, bool isLoadSS, bool DefIsReMat, bool CanDelete, VirtRegMap &vrm, const TargetRegisterClass rc, SmallVector<int, 4> &ReMatIds, const MachineLoopInfo loopInfo, unsigned &NewVReg, unsigned ImpUse, bool &HasDef, bool &HasUse, DenseMap<unsigned,unsigned> &MBBVRegsMap, std::vector<LiveInterval> &NewLIs);
К счастью, эту байду уже выпилили после замены "лишь бы работал" инструкшн шедулера на замудренный "greedy".

@arrowdodger:
arrowdodger

Ну вот и свершилось — LLVM-based линкер: lists.cs.uiuc.edu

@arrowdodger:
arrowdodger

В LLVM потихоньку попиливается libObject — либа для работы с MachO, ELF, COFF. Большей частью там пока что MachO.