Наверное у всех прогеров, использующих язык программирования Цэ, на слуху избитое утверждение, а-ля "си - это высокоуровневый ассемблер". И таки да, сложно не согласиться. Все управляющие операторы легким взмахом руки можно перевести в небольшие ассебмлерные конструкции. Как говорится "иду я по полю с автоматом, никого не трогаю ... и вдруг из-за угла выезжает танк!". И на броне у него написано LLVM...
Согласно последним исследованиям британских ученых такие языки программирования как C++, Go, Haskell, Fortran, rust, Javascript, Ruby, C# уже переметнулись на "сторону врага" (LLVM). Самое интересное, так и Цэ тоже с ними!!!
Собственно, вопросы!
1) Как вы считаете, нужно ли язык Цэ лишить права называться "высокоуровневый ассемблер" за предательство?
2) Ну почему, ну почему LLVM, а не бэкэнд-прослойка в виде Цэ? Почему LLVM?!!
Общаемся аккуратно и по делу, название темы уже "прямо трИсет" модераторскую руку перенести тему в холивары.
Но она еще не там. И так хочется услышать сперва именно сишников. Понеслась.
Всем - счастья!
Автор: amk 06.12.18, 17:07
1) Не нужно. LLVM вполне себе низкоуровневый язык виртуальной машины а никак не "высокоуровневый ассемблер" 2) Потому что см. ответ на п. 1 И где можно почитать про этот Цэ?
Все управляющие операторы легким взмахом руки можно перевести в небольшие ассебмлерные конструкции.
А всякие оптимизации кто делать будет? А в ассемблерные инструкции под какую архитектуру процессора? Что-то лёгкий взмах уже не такой лёгкий оказывается.
Про остальные ЯП прошу отнестись к гуглению более серьйозно!
Отнесись, в чём проблема?
Автор: Qraizer 07.12.18, 19:56
JoeUser, смотри на LLVM как на переносимый ассемблер. По сути так и есть, т.к. бэкенд-компайлер из LLVM в натив входит в любую компилирующую среду разработки, использующую LLVM как промежуточную платформу.
Разного уровня же вещи. Простой пример. SPIR-V транслируется один в один и в обе стороны с LLVM. Для си такое вряд ли бы стало возможным. Можешь сравнить с встроенным C в open cl, как вариант.
Автор: negram 09.12.18, 14:12
ой мама. Набросай-ка jit на C, а потом рассказывай про ненужность LLVM. LLVM -- фреймворк для построения компиляторов. C - компилируемый язык программирования, по-моему, они созданы друг для друга. И ещё много для чего
Автор: applegame 10.12.18, 05:40
Чота какой-то крайне унылый вброс. Как будто вбрасывающий сделал это от отчаяния, в попытке хоть как-то расшевелить форум.
Автор: LMM 10.12.18, 13:33
M
LLM, покайся! Не знаю, Борис ли ты - но ты непарв!
Ну што?!! Вторая часть марлезонского балета, господа присяжные заседатели!
С вашего позволения - командовать парадом буду я (L) ...
Для начала разговора давайте освежим в памяти все аспекты LLVM по скромной ссылке из вики - это лежит тут. Чтобы ничего не убежало из нашего пристального взгляда, мы должны понимать, что любая глава из вышеуказанной ссыли имеет значение, (пусть) равное и (пусть) неоспоримое.
Итак ... читаем "LLVM (ранее Low Level Virtual Machine[5]) — универсальная система анализа, трансформации и оптимизации программ, реализующая виртуальную машину с RISC-подобными инструкциями". Да, действительно, когда-то, когда многие из спопящих заканчивали средние классы не мение средней школы, такие системы на базе RISC-технологии, как UltraSPARC - считались просто божеством тогдашних технологий. Я не ёрничаю, современный комп от интела, стоящий рядом в моей лабе имел целых!!! 16 Мегабайт оперативы. Я боюсь быть позорно неточным, в той лабе я поработал по переводу месяца три, но на слуху отложилось, что лаба тестировала некий симбиоз аппрататно-программного АЛУ на 64 RISC-процах. Для точночти - примерно 1993 год, тогда еще Институт Технической Кибернетики Академии Наук БССР (позже уже РБ). Исторический экскурс заканчиваем ...
Итак LLVM и подход-RISC
Чем же это было революционно в то время? Если грубо - упрощаем набор команд (не по количеству, а по скорости исполнения, по тактам), строим и оптимизируем кэширование, уже потом - строим предугадывание. Не, чо, все ровно!!! На то время модно и современно. LLVM это все патриотично впитал, нет базара!
А что сегодня?
А давно уже сегодня появилась тьма спецификаций типа SSE и иже с ней куча версий до сего дня. Стопэ, товарисчи, а туда ли мы идем??! Сперва была попытка все раздербанить на "сложение/вычитание", а тут все наоборот, штоле?!!! Какие-то скалярные типы (команды а ля CVTSI2SS, CVTSS2SI, CVTTSS2SI), упакованные типы (команды а-ля CVTPI2PS, CVTPS2PI, CVTTPS2PI), почему-то к кэшу дали доступ (команды а-ля MOVNTQ, MOVNTPS, MASKMOVQ, PREFETCH0, PREFETCH1, PREFETCH2, PREFETCHNTA, SFENCE), что за бесовщина?! Омериканская холодная война в области IT?
Меня тут типа спрашивали
Цитата
ой мама. Набросай-ка jit на C, а потом рассказывай про ненужность LLVM
А в чем проблема? Сам LLVM на машинном коде писан? Все конструкции LLVM можно реализовать на Цэ. Только вот возникает вопрос ... Почему некоторая часть IT-комьюнити уже некоторое время задается вопросом "а не создать ли нам аппаратный Forth-процессор?". Я понимаю, лавэ, то, се, интересы жЫрных компаний ... Но тренд каков? Опять не в пользу RISC-подхода! Я человек не обремененный социальными обязательствами, могу дополнить - Цэ универсален! Можно и в системную область влезть, можно и в предметную и выше.
JoeUser, смотри на LLVM как на переносимый ассемблер. По сути так и есть, т.к. бэкенд-компайлер из LLVM в натив входит в любую компилирующую среду разработки, использующую LLVM как промежуточную платформу.
Да, дружище - ты прав! На счет LLVM. Но и Си - "как на переносимый ассемблер". Не? А ведь он не на столько "высокоуровнее"))) Отношу тебя к стате в вики по LLVM (по типам тамошних данных, операциями с памятью, операциям) ... Ну вот скажи чо, это Цэ не может? (про реализацию компайлеров не говори - прокляну!)
С бестами и регардами,
JoeUser
.
Автор: D_KEY 11.12.18, 17:56
Давай знаешь что сделаем? Ты можешь озвучить один небольшой тезис(одно-два предложение)? И попробуем обсудить только его. Для начала.
А то тяжело.
Добавлено
Или давай рассмотрим один из аспектов llvm - готовая инфраструктура для backend компилятора. Чем активно пользуются. Один из примеров - kotlin native, который не стал городить собственный бэкенд, а получил его на халяву (ну почти).
Почему некоторая часть IT-комьюнити уже некоторое время задается вопросом "а не создать ли нам аппаратный Forth-процессор?".
Об аппаратном forth-процессоре речь ведётся с момента появления самого языка FORTH. А это 70-е годы - более 40 лет.
Точно так же велась речь о создании LISP-процессора.
И, внимание, оба были в своё время созданы. Тут вопрос в другом, почему сейчас про них все напрочь позабыли и поднимают вопрос о создании такого процессора снова?
Си получил такое звание - "переносимый ассемблер" - потому, что давал сравнимые с автокодами возможности по доступу к аппаратуре ЭВМ, и в то же время мог был достаточно эффективно реализован на всех существующих платформах.
Об аппаратном forth-процессоре речь ведётся с момента появления самого языка FORTH. А это 70-е годы - более 40 лет.
Точно так же велась речь о создании LISP-процессора.
Можно ссыль? Ни разу не слышал об аппаратном Форт-процессоре
D_KEY, давай на затравки просто скромно изменим на твоей схеме - заменим блок "LLVM оптимизатор" на схожий "Си оптимизатор"... Неужели синтаксис Си так убог по сравнению с синтаксисом LLVM???
Да, действительно, когда-то, когда многие из спопящих заканчивали средние классы не мение средней школы, такие системы на базе RISC-технологии, как UltraSPARC - считались просто божеством тогдашних технологий
В смысле «считались»? SPARC и сейчас вполне хорошие процы, не то что эти ваши meltdown'утые интели-шминтели.
In the 21st century, the use of ARM architecture processors in smartphones and tablet computers such as the iPad and Android devices provided a wide user base for RISC-based systems. RISC processors are also used in supercomputers such as Summit, which, as of November 2018, is the world's fastest supercomputer as ranked by the TOP500 project.
модераторскую руку перенести тему в холивары.
Вторая часть марлезонского балета, господа присяжные заседатели!
