Бессмысленное программистское
Apr. 26th, 2013 06:05 am1. Утверждение, что Си суть портабельный ассемблер, не совсем верно. Это портабельный 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
Date: 2013-05-09 12:17 am (UTC)У Си нет данной проблемы. Если я пишу C backend для компилятора, мне не надо думать об этих деталях.
> это Си вот решает на разных платформах одинаковую структуру лейаутить по-разному.
Речь идёт о calling convention а не о layout. Си ничего не решает. Target ABI задаётся разработчиками архитектуры. Предполагаемая библиотека может быть написана на чём угодно.
> LLVM-овский IR, если всё это делать в нём
Придётся фиксировать Target ABI. Разработчики Pnacl вот пошли по этому пути. Remains to be seen, можно ли будет такой код запускать на 16-битном процессоре.
no subject
Date: 2013-05-09 12:54 am (UTC)*shrug* у Си нет данной проблемы, пока он не сталкивается с библиотекой, написанной на LLVM IR. Так же, как у LLVM IR нет такой проблемы, пока он не сталкивается с библиотекой, написанной на Си.
Си ничего не решает. Target ABI задаётся разработчиками архитектуры.
[citation needed]. ABI как раз задаётся разработчиком OS или библиотеки, к которой этот ABI относится (например, iBCS разработан юниксовыми вендорами), calling convention задаётся разработчиками компиляторов (в частности, на одной и той же архитектуре он у разных языков разный), и т.д. Во всех этих случаях родной язык для этих самых разработчиков имеет немалое значение.
no subject
Date: 2013-05-09 01:50 am (UTC)LLVM IR не в вакууме существует. Коду надо как-то системные функции вызывать, даже чтобы сказать hello world.
Библиотеки, написанные на LLVM IR это фантом из страны фантазии.
> [citation needed]. ABI как раз задаётся разработчиком OS или библиотеки
Да, я упростил. См. например ARM EABI. Если компилятор моего языка выдаёт совместимые .o, то их можно линковать с любыми другими совместимыми объектными файлами.
> в частности, на одной и той же архитектуре он у разных языков разный
А часто и у разных компиляторов одного языка или у разных версий одного компилятора. Однако есть lingua franca.
To sum up: если я пишу backend для компилятора и заинтересован в основном в портабельности генерируемого кода, то мне лучше использовать Си, а не LLVM IR.