T был одной из лучших реализаций языка программирования Lisp и установил стандарт лаконичного дизайна, который был превзойдён лишь немногими более новыми диалектами. В этой статье Олин Шиверс вспоминает историю T.
Изучение и понимание неопределённого поведения — важный шаг для разработчика C++, поскольку undefined behavior бывает источником серьёзных ошибок и проблем в программах. UB может проявляться в разных аспектах языка, включая операции с памятью, многопоточность, арифметические вычисления, работу с указателями и так далее.
Под катом мы погрузимся в мир неопределённого поведения в C++ и рассмотрим некоторые примеры ситуаций, в которых оно может возникать.
P.S.: Часть приведённых в статье примеров вдохновлены материалами, которые можно посмотреть в разделе «Полезные ссылки».
Вообще-то, третья статья данного цикла должна была рассказывать о конкретных оптимизациях. Но пока я прикидывал её план, стало ясно, что без освещения некоторых аспектов неопределённого поведения многое из дальнейших описаний будет непонятно. Поэтому сделаем ещё один осторожный шаг, прежде, чем окунаться в омут с головой.
Наверное, многие слышали, что неопределённое поведение (undefined behavior, UB) -- постоянный источник разнообразных багов, иногда очень забавных, иногда довольно жутких. Тема также неоднократно освещалась и на Хабре, навскидку раз, два, три (и даже целый тег есть). Однако чаще всего статьи по данной теме посвящены тому, как можно отстрелить себе ногу, голову или случайно сжечь свой жёсткий диск, исполнив какой-нибудь опасный код. Я же намерен сделать акцент на том, зачем авторы языков программирования надобавляли всей этой красоты, и как оптимизатор может её эксплуатировать. Всё будет проиллюстрировано наглядными примерами из LLVM и присыпано байками из собственного опыта, так что наливайте себе чай, располагайтесь поудобнее, и погнали.
Архитектура RISC-V корнями уходит к началу 1980-х годов, группа под руководством Дэвида Паттерсона в стенах университета Беркли разработала архитектуры RISC-I и RISC-II. Долгое время архитектуре приходилось существовать в тени лицензируемых ARM и MIPS ядер. Архитектура RISC-V появилась в 2010 году, и поддерживается Linux Foundation. Отметка в 10 миллиардов произведенных ядер была преодолена за 12 лет.
Сейчас RISC-V может сыграть большую роль в становлении российской микроэлектроники. Компании CloudBEAR и Syntacore работают над процессорами собственной микроархитектуры, совместимыми с системой команд RISC-V. Архитектура RISC-V позволяет нашим разработчикам создавать энергоэффективные процессоры сравнимого с мировым уровня и сохранять программную совместимость со всеми программами, созданными для экосистемы RISC-V во всем мире.
В данной статье мы попробуем на примере RISC-V платы MangoPi разобраться, как выполняется кросс-компиляция под RISC-V.
Системное программирование и разработка процессоров — область достаточно узкая, из-за чего её часто воспринимают как что-то непонятное и недоступное. Хотим поделиться новым подкастом «Битовые маски», который планирует исправить это впечатление. В каждом выпуске будем общаться с инженерами, причастными к созданию продуктов, которыми многие программисты пользуются ежедневно, и разбирать с ними интересные нюансы, мифы и задачи отрасли.
Гостем первого эпизода стал Дмитрий Петров, писавший компилятор для Kotlin. Под катом вы найдете запись, а для тех, кто не любит слушать — мы подготовили расшифровку ряда интересных фрагментов. Мы очень хотим фидбека: не стесняйтесь писать в комментарии или личные сообщения.
Brainfuck — очень глупый язык. Там есть лента из 30к ячеек, по байту каждая. Команды bfc это:
< и >)+ и -). и ,)[ и ] это начало и конец цикла соответственноПрограммировать на bfc сложно. Но, как известно, любую проблему можно решить добавлением слоя абстракции (кроме проблемы большого количества абстракций).
Команда Rust рада сообщить о новой версии языка — 1.70.0. Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение.
Если у вас есть предыдущая версия Rust, установленная через rustup, то для обновления до версии 1.70.0 вам достаточно выполнить команду:
rustup update stableЕсли у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта, а также посмотреть подробные примечания к выпуску на GitHub.
Если вы хотите помочь нам протестировать будущие выпуски, вы можете использовать beta (rustup default beta) или nightly (rustup default nightly) канал. Пожалуйста, сообщайте обо всех встреченных вами ошибках.
Тема непосредственно самого процессора Эльбрус уже достаточно хорошо раскрыта в различных статьях, в том числе, в статьях, опубликованных на habr.ru. Кроме самого процессора Эльбрус время от времени на просторах рунета можно встретить обсуждения, посвященные вопросу портирования компилятора clang/llvm на Эльбрус. Пожалуй, данная тема еще не получала подробного освещения. Данная заметка призвана заполнить этот «пробел».
Если вкратце, то llvm из e2k-дистрибутива портируется на базе оптимизирующего компилятора LCC. Ну а тем, кому нужно больше подробностей, то добро пожаловать «под кат».
Как известно, интерпретируемые и компилируемые языки имеют преимущества и недостатки относительно друг друга. Одним из таких преимуществ/недостатков является сохранение связи имени переменной из исходного текста с соответствующим объектом программы во время выполнения.
Для интерпретируемых языков эта связь естественным образом сохраняется, так как интерпретатор собственно и «выполняет» исходный текст программы, т.е. имеет к нему непосредственный доступ.
В случае же компилируемых языков, имена переменных из исходного текста уже были использованы на этапе компиляции и обычно на этапе выполнения недоступны и кажутся ненужными.
Я уже писал заметку об этом и вот решил продолжить тему второй частью. Для тех, кто не любит ходить по ссылкам, кратко напомню, о чем шла речь в первой части.
Сегодня мы продолжаем наш разговор об оптимизирующих компиляторах для самых маленьких и не очень. Для тех, кто пока не в курсе происходящего, но желает приобщиться - я поставил себе задачу написать цикл вводных статей в эту область для совсем-совсем начинающих. Первую часть, где рассказывается об SSA-форме, можно и нужно прочитать здесь.
Сегодня мы поговорим о доминировании. Это одна из фундаментальных вещей, на которых стоит как теория компиляторов вообще, так и многие компиляторные оптимизации в частности. Пристегните ремни и запишите стоп-слово на бумажке, чтобы не забыть.
Позапрошлую заметку я начинал словами «вот уже 10 лет прошло…», а эту можно было бы начать «вот уже 20 лет прошло…». Хотя там речь шла лишь о выравнивании стека, а здесь – о целой организации взаимодействия программы с WinAPI. Помнится, здесь недавно в комментариях кто-то наивно удивлялся: зачем вы приводите устаревший и никому не интересный способ программирования через WinAPI? А как же иначе программа вообще может взаимодействовать со средой Windows, как не через вызовы ее стандартных функций? Через имеющиеся надстройки над WinAPI не все можно сделать.
Конечно, было бы прекрасно все время оставаться в рамках парадигмы используемого языка программирования и чтобы «на фотографии не торчали уши фотографа», т.е. чтобы в исходных текстах никак не проявлялись бы особенности взаимодействия со средой. Например, в большинстве языков есть понятие файла. Чтобы открыть файл не обязательно явно описывать стандартную функцию из WinAPI CreateFile или OpenFile, поскольку компилятор переведет встроенный в язык оператор открытия или прямо к обращению к этой функции или к вызову системной библиотеки, которая где-то внутри себя и вызовет требуемую функцию. В любом случае программист не обязан знать, как именно это реализовано в Windows.
В системной библиотеке языка PL/1-KT, который я использую, имеется обращение лишь к 28 функциям WinAPI и это вполне покрывает «обычные» возможности языка и можно было бы не заботиться о явных вызовах. Но увы, часто этого мало. И хотя нормальные люди ходят в двери, а не в окна (ах, какая свежая, искрометная шутка!), приходится в программах явно обращаться к функциям типа CreateWindow или CloseWindow. А это уже ну никак не входит в понятия языка.
Всем привет. Сегодня я хотел бы поговорить об устройстве современных оптимизирующих компиляторов. Я никогда не публиковался на Хабре ранее, но надеюсь, что мне удастся написать серию статей, которая просуммирует мой опыт в этой области.
Коротко обо мне. Меня зовут Макс, и так получилось, что я вот уже 10 лет, почти с самого начала своей карьеры, занимаюсь оптимизирующими компиляторами. Я начинал в Intel, потом перешёл в Azul Systems, год провёл в Cadence и вернулся обратно, всё это время занимаясь компиляторными оптимизациями для Java, C++ и нейросетевых моделей. На момент написания статьи у меня чуть за 900 патчей в LLVM, большинство из них посвящено цикловым оптимизациям.
За это время я провёл десятки собеседований на позиции как интернов, так и инженеров сеньорного уровня, и довольно часто люди, приходя на эти собеседования, многих вещей не знают или знают поверхностно. И я подумал: а мог бы я написать такой цикл статей, чтобы человек, прочитав их, узнал бы всю ту базу, которая, на мой собственный взгляд, необходимо начинающему компиляторному инженеру? Очень бы хотелось, чтобы новичку в этой области можно бы было дать один (относительно небольшой по объёму) набор текстов, чтобы он получил оттуда всё необходимое для старта. Это не перевод, текст оригинальный, поэтому в нём могут быть ошибки и неточности, которые я буду рад исправить, если вы мне их укажете.
Итак, поехали.
Некоторое время назад я добавил в свой язык программирования Ü такой функционал, как генераторы. В этой статье я хочу поведать, как это было сделано и зачем.
Данная статья будет полезна как интересующимся компиляторостроением, так и тем, кому интересно внутреннее устройство генераторов в частности и корутин вообще.
После трёх лет неторопливой разработки вышла версия 1.0 моего скриптового языка Umka. Это статически типизированный язык, предназначенный для встраивания в программы на C/C++. Синтаксис и некоторые особенности семантики Umka были вдохновлены языком Go, однако Umka никак не зависит от экосистемы Go и не требует для работы ничего, кроме стандартной библиотеки C.
Основным применением языка стал игровой фреймворк Tophat, созданный Марком Машкаринцем. Версия Tophat 1.0 вышла одновременно с Umka. Это очень простой модульный фреймворк для создания 2D игр. Несколько мини-игр на нём были написаны для участия в джемах. Сейчас в разработке находятся два более крупных игровых проекта — платформер-головоломка и игра о диспетчеризации железнодорожного движения.
float Q_rsqrt( float number )
{
long i;
float x2, y;
const float threehalfs = 1.5F;
x2 = number * 0.5F;
y = number;
i = * ( long * ) &y; // зловещий хакинг чисел с плавающей запятой на уровне битов
i = 0x5f3759df - ( i >> 1 ); // какого чёрта?
y = * ( float * ) &i;
y = y * ( threehalfs - ( x2 * y * y ) ); // первая итерация
// y = y * ( threehalfs - ( x2 * y * y ) ); // вторая итерация, можно удалить
return y;
}
Сначала я хотел назвать эту заметку «Редактор связей? Это очень просто». Именно так называл свои прекрасные книжки Евгений Айсберг: «Радио? Это очень просто!», «Телевидение? Это очень просто!» Но поскольку я уже использовал эту шутку в статье о планировщике Windows, чтобы не повторяться, теперь использую любимую формулу многих журналистов: «Вся правда о…».
На самом деле никакую ужасную правду о редакторе связей раскрывать не требуется. Для программистов старшего поколения эта заметка вообще вряд ли будет интересна, поскольку в ней описываются банальные вещи. Но я, к сожалению, неоднократно сталкивался с самыми дикими представлениями о работе, например, компилятора или того же редактора связей у молодого поколения работников ИТ. И я их даже не обвиняю. На фоне чудовищного потока информации в современном программировании заставлять кого-то еще шарить по книгам и сайтам, чтобы разобраться, как работает утилита, внутрь которой они никогда не полезут – это даже не этично.
Другое дело я, который сопровождает и даже по мере сил развивает средства программирования. Приходится разбираться и с работой редактора связей, а, значит, как говорится, мне и карты в руки. Попробую кратко и на пальцах объяснить назначение и работу этого программного инструмента. И не просто объяснить, а привести примеры из конкретной реализации. Иначе абстрактные рассуждения плохо воспринимаются. Сам не люблю лекторов, которым кажется, что им достаточно поводить пальцем в воздухе, чтобы аудитория все поняла с полуслова. Так не бывает.
Команда Rust рада сообщить о новой версии языка — 1.69.0. Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение.
Если у вас есть предыдущая версия Rust, установленная через rustup, то для обновления до версии 1.69.0 вам достаточно выполнить команду:
rustup update stableЕсли у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта, а также посмотреть подробные примечания к выпуску на GitHub.
Если вы хотите помочь нам протестировать будущие выпуски, вы можете использовать beta (rustup default beta) или nightly (rustup default nightly) канал. Пожалуйста, сообщайте обо всех встреченных вами ошибках.
В предыдущей статье мы закончили на том, что добавили в наш учебный язык поддержку строк, указателей, массивов, структур, а так же операции для работы с ними. В этой части мы продолжим расширять дынный языка и добавим в него: классы с динамической диспетчеризации методов, одиночным наследованием и поддержку перегрузки функций на основе их параметров.
Вот уже 10 лет прошло, как я переводил свои средства программирования в среду x86-64 для Windows 7. А как будто вчера было! Поскольку тогда многие особенности этой среды были для меня внове, они вызывали недоумение. Вот типичный пример.