![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Бессмысленное программистское
1. Утверждение, что Си суть портабельный ассемблер, не совсем верно. Это портабельный C-style ассемблер, в нём много чего нельзя по-человечески сделать из того, что на нормальном ассемблере делается совершенно тривиально (нетошнотворный Forth's NEXT, например).
2. Если же говорить о портабельном C-style ассемблере, то на эту роль LLVM-овский IR подходит чуть более, чем хорошо. Ну да, будет повербознее, зато гибкость и краса необычайные. Ограничения всё те же -- push сделать нельзя, jmp толком сделать нельзя, и т.д. Ну, C-style, как и было сказано. Надо почитать, как они делают longjmp, но лень. Архитектурно-специфичным кодом же небось, скучно.
3. (unrelated) Людям, которые придумывали x87 floating point arch, хочется сказать что-нибудь не очень приятное. Ну понятно, почему всё так ужасно вышло, но простить это сложно. Т.е. у вас есть FPU, и он умеет трапаться, например, по stack underflow, но трапнется он на следующей FPU-инструкции после той, которая вызвала проблему. Т.е. resume сказать нельзя, и т.д. Who does that?! (машет рукой и удаляется, боромоча)
2. Если же говорить о портабельном C-style ассемблере, то на эту роль LLVM-овский IR подходит чуть более, чем хорошо. Ну да, будет повербознее, зато гибкость и краса необычайные. Ограничения всё те же -- push сделать нельзя, jmp толком сделать нельзя, и т.д. Ну, C-style, как и было сказано. Надо почитать, как они делают longjmp, но лень. Архитектурно-специфичным кодом же небось, скучно.
3. (unrelated) Людям, которые придумывали x87 floating point arch, хочется сказать что-нибудь не очень приятное. Ну понятно, почему всё так ужасно вышло, но простить это сложно. Т.е. у вас есть FPU, и он умеет трапаться, например, по stack underflow, но трапнется он на следующей FPU-инструкции после той, которая вызвала проблему. Т.е. resume сказать нельзя, и т.д. Who does that?! (машет рукой и удаляется, боромоча)
no subject
А как тебе идея что портабельный ассемблер это уже не IR, а яваскрипт, вернее Asm.js ? Меня чем больше я это думаю тем больше прет.
(IR -> Asm.js это emscripten)
no subject
no subject
no subject
Это утверждение совсем не верно, и растет, как обычно, из того обстоятельства что программирование, как и любовь, это одно слово, подразумевающее множество разнообразнейших занятий. Верным является другое утверждение: Си это язык программирования чьи конструкции позволяют прямое отображение на команды процессоров. Соответственно, если глядеть из вариаций программирования где цена разработки важнее чем потери десяток и сотен процентов производительности, разница между Си и ассемблером представляется незаметной.
no subject
no subject
no subject
А поскольку LLVM IR более низкоуровневый, чем Си, появляются проблемы, которых нет в Си. Вот один из примеров (http://llvm.org/devmtg/2011-09-16/EuroLLVM2011-MoreTargetIndependentLLVMBitcode.pdf) (см. слайд 11): функция, которой по значению передаётся
struct { int a; char b; }. На x86 она получает один указатель, а на ARM это два int32.То есть на Си мы можем просто сказать "вызвать эту функцию из библиотеки", а на уровне LLVM IR должны думать о target ABI. В Pnacl они по этой причине просто делают вид, что целевая архитектура это некая виртуальная 32-битная LE машина.
no subject
Это, собственно, вопрос оптики. Проблема с портабельностью есть тут, с таким же успехом, у Си, а не у LLVM -- потому что это Си вот решает на разных платформах одинаковую структуру лейаутить по-разному. LLVM-овский IR, если всё это делать в нём (и программу, и предположительную библиотеку), никаких таких непортабельных фокусов делать не станет, насколько я понимаю.
no subject
У Си нет данной проблемы. Если я пишу C backend для компилятора, мне не надо думать об этих деталях.
> это Си вот решает на разных платформах одинаковую структуру лейаутить по-разному.
Речь идёт о calling convention а не о layout. Си ничего не решает. Target ABI задаётся разработчиками архитектуры. Предполагаемая библиотека может быть написана на чём угодно.
> LLVM-овский IR, если всё это делать в нём
Придётся фиксировать Target ABI. Разработчики Pnacl вот пошли по этому пути. Remains to be seen, можно ли будет такой код запускать на 16-битном процессоре.
no subject
*shrug* у Си нет данной проблемы, пока он не сталкивается с библиотекой, написанной на LLVM IR. Так же, как у LLVM IR нет такой проблемы, пока он не сталкивается с библиотекой, написанной на Си.
Си ничего не решает. Target ABI задаётся разработчиками архитектуры.
[citation needed]. ABI как раз задаётся разработчиком OS или библиотеки, к которой этот ABI относится (например, iBCS разработан юниксовыми вендорами), calling convention задаётся разработчиками компиляторов (в частности, на одной и той же архитектуре он у разных языков разный), и т.д. Во всех этих случаях родной язык для этих самых разработчиков имеет немалое значение.
no subject
LLVM IR не в вакууме существует. Коду надо как-то системные функции вызывать, даже чтобы сказать hello world.
Библиотеки, написанные на LLVM IR это фантом из страны фантазии.
> [citation needed]. ABI как раз задаётся разработчиком OS или библиотеки
Да, я упростил. См. например ARM EABI. Если компилятор моего языка выдаёт совместимые .o, то их можно линковать с любыми другими совместимыми объектными файлами.
> в частности, на одной и той же архитектуре он у разных языков разный
А часто и у разных компиляторов одного языка или у разных версий одного компилятора. Однако есть lingua franca.
To sum up: если я пишу backend для компилятора и заинтересован в основном в портабельности генерируемого кода, то мне лучше использовать Си, а не LLVM IR.
no subject