Компиляторы *

Сегодня мы поговорим о том, как перестать считать одни и те же выражения внутри циклов и полюбить вынос инвариантов.

Недавно я реализовал языковой сервер для языка программирования Ü. В этой статье я хочу поведать, как я это сделал. Данное повествование будет полезно для общего понимания, что есть такое языковой сервер. Также статья может быть полезна как руководство для написания языкового сервера для своего языка программирования.

Компилятор C на 500 строк Python? Почему бы и нет? Это сложно, даже если отказаться от многих функций. Но, в то же время, это ужасно интересно, а результат оказался на удивление функциональным и несложным для понимания!

1. Компиляторы умны! Они автоматически векторизуют весь код!
2. Компиляторы тупы, автоматическая векторизация хрупка, ее очень легко нарушить несвязанными изменениями в коде. Всегда лучше вручную написать конкретные инструкции SIMD.
3. Написать SIMD вручную действительно сложно — для каждой архитектуры процессора придется писать разный код. Кроме того, вы, вероятно, понимаете, что компилятор напишет на ассемблере скалярный код лучше вас. Что заставляет вас думать, что вы превзойдете компилятор в SIMD, где еще больше странных инструкций и запретов? Компиляторы — это инструменты. Они могут надежно векторизовать код, если он написан в форме, поддающейся векторизации.

После некоторых поисков серьёзного вызова для анализатора PVS-Studio выбор пал на открытую коллекцию компиляторов GCC. Да, это уже не первая по счёту проверка этого проекта. Однако поддерживаемые этой коллекцией языки программирования не стоят на месте, и их постоянное развитие влечёт за собой соответствующее постоянное усложнение кода GCC. Таким образом цель — обнаружить ошибки в коде GCC с помощью анализатора PVS-Studio.

Команда Rust рада сообщить о новой версии языка — 1.72.0. Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение.

Если у вас есть предыдущая версия Rust, установленная через rustup, то для обновления до версии 1.72.0 вам достаточно выполнить команду:

rustup update stable

Если у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта, а также посмотреть подробные примечания к выпуску на GitHub.

Если вы хотите помочь нам протестировать будущие выпуски, вы можете использовать beta (rustup default beta) или nightly (rustup default nightly) канал. Пожалуйста, сообщайте обо всех встреченных вами ошибках.

В программировании микроконтроллеров часто приходится в UART консоли вводить в прошивку какие-то калибровочные коэффициенты: значения токов, пороговых напряжений, уровней освещений и прочего. Как правило это действительные числа с плавающий запятой в разных форматах.

Потом часто надо анализировать текстовые логи с SD-карты. Надо выхватывать вещественные числа из CSV файлов для дальнейших расчетов.

Для всего этого нужен какой-то надежный переносимый прозрачный и простой алгоритм, чтобы распознавать вещественные числа из строчек.

В этом тексте я представил решение этой задачи.

В предыдущей серии мы научились считать выражения вида -2.1+ .355 / (cos(pi % 3) + sin(0.311)). Один из комментариев там предложил посчитать то, что я вынес в заголовок этого поста. Что ж, вызов принят. Как и в предыдущем посте, мы "на пальцах" разбираем устройство простейшего интерпретатора.

Не так давно, мы уменьшили на 20% объем итогового скомпилированного JavaScript-кода в Visual Studio Code. В абсолютных числах это около 3.9 МБ. Хоть это и меньше типичной гифки из блога, цифра все равно значительная! Это положительно влияет не только на объем скачиваемых данных для очередного обновления, но и на время запуска: меньше кода значит меньше работы для парсера и интерпретатора. И ко всему прочему, мы добились этого без удаления кода или каких-либо рефакторингов. Вместо этого, мы работали над новым шагом сборки: name mangling, сокращение имен сущностей.

В этой статье рассказывается, как мы обнаружили возможность такой оптимизации, какие подходы рассматривали, и как в конце концов добились уменьшения размера на 20%.

Некоторое время назад в Интернете ходила статья о неопределённом поведении, просто бесившая коренную аудиторию Rust. Завсегдатаи С и C++ в ответ только бурчали, что кто-то просто не понимает Всех Тонкостей и Нюансов Их Светлейшего Языка. Как обычно, пришло время и мне постараться изо всех сил и вставить мои пять копеек в эту застарелую дискуссию.

Готовьтесь поговорить об Основной Проблеме языков C и C++, а также о Принципе Лома.

Управляющие конструкции языка программирования Аргентума основанны не на типе Boolean а на типе Optional. Это имеет далеко идущие последствия для надежности, выразительности и удобочитаемости.

Некоторое время назад я разработал режим GNU Emacs для редактирования конфигурационных файлов операционной системы Embox. Кроме всестороннего изучения Emacs Lisp мне потребовалось разобраться со структурой модуля режима, а также процессом и требованиями к публикации пакетов в MELPA, наиболее популярном архиве пакетов для GNU Emacs. В этом руководстве я расскажу, что нужно знать, чтобы написать свой собственный режим, и как опубликовать свой собственный пакет.

Мы продолжаем цикл статей, посвящённых теме undefined behavior. Ранее мы исследовали предпосылки неопределённого поведения в C++, предоставили формальные определения и рассмотрели несколько примеров. Сегодня углубимся в проблему: сосредоточимся на случаях UB при многопоточности и неправильном использовании move-семантики.

Подобные ситуации могут казаться тривиальными на первый взгляд. При этом они служат основой для более сложных и реальных сценариев, с которыми разработчики порой сталкиваются в своей практике.

• улучшенный static_assert,
• переменная _,
• оптимизация и улучшение для std::to_string,
• Hazard Pointer,
• Read-Copy-Update (так же известное как RCU),
• native_handle(),
• целая вереница классов *function*,
• множество доработок по constexpr,
• std::submdspan,
• и прочие приятные мелочи.

Это история о баге, который бы заставил вас рвать на себе волосы. Из-за такого бага вы можете подумать: «Но это невозможно, должно быть, компилятор сломался, других вариантов нет!»

А баг компилятора — это серьёзно: за двенадцать лет программирования на C++ я обнаружил (и написал отчёт) всего... об одном. И могу сказать, что перед отправкой отчёта о баге GCC, я максимально тщательно протестировал и проверил его, чтобы не выглядеть идиотом.

Впрочем, ладно, вот моя история.

В этой статье мы поговорим о классе оптимизаций, которые позволяют избегать лишних вычислений при помощи переиспользования уже имеющихся результатов, а именно -- оптимизации семейств CSE, GVN и PRE. В разном виде такие оптимизации есть практически во всех известных компиляторах.

Очень часто кто-то где-нибудь на каком-нибудь форуме жалуется на нехватку инкапсуляции и изоляции в языке программирования C. Это происходит с такой регулярностью, что я намерен раз и навсегда разрушить этот миф. Благодаря этому когда в следующий раз кто-то будет делать подобные заявления, я смогу просто дать ссылку на эту страницу, а не писать объяснение заново.

Нужно сказать, что C – это старый язык, в котором не хватает множества современных возможностей. Но чего в нём хватает, так это инкапсуляции и изоляции.

Как язык программирования Аргентум делает быстрый dynamic_cast и диспетчеризацию методов интерфейсов четырьмя инструкциями процессора.