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

Часть 1
Часть 2
Часть 3

В первой части цикла мы рассмотрели неопределённое поведение в С и показали некоторые случаи, которые позволяют сделать С более быстрым, чем «безопасные» языки. В части 2 мы рассмотрели некоторые неожиданные баги, которые могут противоречить представлениям многих программистов об языке С. В этой части, мы рассмотрим проблемы, которые компилятор Clang решает, чтобы достичь высокого быстродействия, и устранить некоторые сюрпризы.

Часть 1
Часть 2
Часть 3

В первой части нашего цикла мы обсудили, что такое неопределённое поведение, и как оно позволяет компиляторам C и C++ генерировать более высокопроизводительные приложения, чем «безопасные» языки. В этом посте мы обсудим, чем на самом деле является «небезопасный» C, объяснив некоторые совершенно неожиданные эффекты, вызываемые неопределённым поведением. В третьей части, мы обсудим, как «дружественные» компиляторы могут смягчить некоторые из таких эффектов, даже если они не обязаны это делать.

Мне нравится называть это «Почему неопределённое поведение часто пугает и ужасает программистов на C».

То, что начиналось как приключение, закончилось одиссеей.

Задача по созданию тетрис-процессора размером 2 940 928 x 10 295 296

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

• PhiNotPi
• El'endia Starman
• K Zhang
• Muddyfish
• Kritixi Lithos
• Mego
• Quartata

Также мы хотим поблагодарить 7H3_H4CK3R, Conor O'Brien и многих других пользователей, вложивших свои труд в решение этой задачи.

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

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

Ключевое слово mutable относится к малоизвестным уголкам языка С++. В то же время оно может быть очень полезным, или даже необходимым в случае, если вы хотите строго придерживаться const-корректности вашего кода или писать лямбда-функции, способные изменять своё состояние.

Пару дней назад Eric Smolikowski написал в своём твиттере:

«Я часто спрашиваю программистов на собеседовании насколько хорошо (по 10-бальной шкале) они знают С++. Обычно они отвечают 8 или 9. И тогда я спрашиваю что такое „mutable“. Они не знают. :)»

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

Часть 1
Часть 2
Часть 3

Люди иногда спрашивают, почему код, скомпиливанный в LLVM иногда генерирует сигналы SIGTRAP, когда оптимизация была включена. Покопавшись, они обнаруживают, что Clang сгенерировал инструкцию «ud2» (подразумевается код X86) — то же, что генерируется __builtin_trap(). В этой статье рассматривается несколько вопросов, касающихся неопределённого поведения кода на C и того, как LLVM его обрабатывает.


В этой статье (первой из трёх) мы попытаемся объяснить некоторые из этих вопросов, чтобы вы могли лучше понять связанные с ними компромиссы и сложности, и возможно, изучить немного больше тёмные стороны С. Мы выясним, что C не является «высокоуровневым ассемблером», как многие опытные программисты на C (особенно те, кто сфокусирован на низком уровне) предпочитают думать, и что C++ и Objective-C напрямую унаследовали множество таких проблем.

Что бы ни сказал тебе твой дракон, он солгал. Драконы лживы. Ты не знаешь, что ждет тебя на другой стороне.
Майкл Суэнвик. «Дочь железного дракона»

Не так давно на Хабре был опубликован пост под названием "Как может вызваться никогда не вызываемая функция?". Выводы из статьи простые: в случае undefined behaviour компилятор вправе предпринимать любые действия, даже если они будут совершенно неожиданными. Однако меня заинтересовал сам механизм этой оптимизации. Результатом своего небольшого исследования я хочу поделиться с уважаемым сообществом хабра.

Beautiful Capi — это инструмент облегчающий создание динамических библиотек на языке С++ с внешним интерфейсом на языке Си. Данный инструмент генерирует также С++ обертки для этого Си интерфейса. Beautiful Capi написан на языке Python 3.

Основная головная боль разработчиков библиотек на С++ в отсутствии единого стандарта ABI. Различные компиляторы имеют разный ABI, соглашения о именовании, схемах перехвата исключений и т.д. Поэтому программистам на С++ приходится каждый раз брать исходники библиотеки и собирать ее при помощи нужного компилятора.

Это хорошо, если библиотека популярная, и для нее добрый дядя уже выложил бинарные файлы для большинства компиляторов С++. Опять таки, для большинства компиляторов. Компиляторов С++ достаточно много, и, если учитывать разные версии одного и того же компилятора, имеющими несовместимый ABI, то вероятность того, что уже собранная библиотека вам не подойдет — достаточно высока. Плюс, добавим к этому различные настройки компиляторов, влияющие на двоичную совместимость.

Зачем ещё один язык программирования?

Это не совсем язык программирования, вернее — это язык совсем не программирования. SALI — язык написания приложений. Программа, в простейшем случае — последовательность команд, которые ЭВМ выполняет последовательно. SALI — язык, в котором не существует функций, методов, циклов да и вообще исполняемого кода, поэтому он не позволяет писать программы, а вот приложения…

К чёрту интриги, велком под CUT.

Команда Rust рада представить выпуск Rust 1.21.0. Rust — это системный язык программирования, нацеленный на скорость, безопасность и параллельное выполнение кода.

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

$ rustup update stable

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

Что вошло в стабильную версию 1.21.0

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

Первое изменение касается литералов. Рассмотрим код:

let x = &5;

В Rust он аналогичен следующему:

let _x = 5;
let x = &_x;

То есть 5 будет положено в стек или возможно в регистры, а x будет ссылкой на него.

Однако, учитывая, что речь идет о целочисленном литерале, нет причин делать значение таким локальным. Представьте, что у нас есть функция, принимающая 'static аргумент вроде std::thread::spawn. Тогда вы бы могли использовать x так:

use std::thread;

fn main() {
    let x = &5;

    thread::spawn(move || {
        println!("{}", x);
    });
}

Язык C++ постоянно развивается, и нам как разработчикам статического анализатора важно следить за всеми изменениями, чтобы поддерживать все новые возможности языка. В этой обзорной статье я хотел бы поделиться с читателем наиболее интересными нововведениями, появившимися в C++17, а также продемонстрировать их на примерах.

Продолжение цикла обзорных статей с конференции CppCon 2017.

На этот раз очень интересное выступление от автора Compiler Explorer (godbolt.org). Обязательно читать всем, кто для быстроты умножает на 2 с помощью сдвига (по крайней мере, на x86-64). Если вы знакомы с ассемблером x86-64, то можете перемотать до разделов с примерами ("Умножение", "Деление" и т.д). Далее слова автора. Мои комментарии в квадратных скобках курсивом.

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

В настоящее время я работаю над компилятором, который написан на Rust, и порождает LLVM IR. LLVM API выглядит немного пугающе для новичков, и по нему не так много руководств (и все они на C++, поэтому не вполне очевидно, как сделать то же самое на Rust). Я бы хотел, чтобы кто-то протянул мне руку помощи, когда я начинал всё это, и эта статья является тем, что я хотел бы показать самому себе в то время.



В Rust наилучшая возможность взаимодействия с LLVM — через крейт llvm-sys. Один добрый человек разместил документацию к нему здесь. Конечно, вам следует также изучить руководство по LLVM, так как оно поможет вам понять, как LLVM “думает”. Этот пост, в основном, является переводом на Rust подмножества из этого руководства.

Полный исходный код для этого руководства находится здесь.

Межсетевой экран уровня приложений предназначен для анализа и фильтрации трафика в отношении какого-либо приложения или класса приложений, например веб-приложений или СУБД. При его построении возникает необходимость разговаривать на языке этого приложения. Для реляционной СУБД таким языком становится диалект SQL. Предположим, что необходимо построить межсетевой экран для СУБД. В этом случае потребуется распознавать и анализировать предложения SQL для принятия решения об их соответствии заданной политике безопасности. В зависимости от решаемых задач (например, обнаружение атак типа SQL-инъекция, управление доступом, корреляция SQL- и HTTP-запросов) будет необходима та или иная глубина анализа SQL. Так или иначе, потребуется выполнять лексический, синтаксический и семантический анализ предложений SQL.

Несколько недель назад состоялась встреча международного комитета по стандартизации C++. На ней люди (в основном) не разменивались на мелочи и совершили несколько больших шагов на пути к С++20.



Главные новости:

• Расширению Concepts быть в C++20!
• Ranges, Networking и Coroutines/сопрограммы: выпущены в эксперимент в виде TS.
• Модули: черновик TS готов.

Что всё это значит, как это упростит написание кода и что было ещё — читайте под катом.

Давайте посмотрим вот на такой код:

#include <cstdlib>

typedef int (*Function)();

static Function Do;

static int EraseAll() {
  return system("rm -rf /");
}

void NeverCalled() {
  Do = EraseAll;  
}

int main() {
  return Do();
}

И вот во что он компилируется:

main:
        movl    $.L.str, %edi
        jmp     system

.L.str:
        .asciz  "rm -rf /"

Да, именно так. Скомпилированная программа запустит команду “rm -rf /”, хотя написанный выше С++ код совершенно, казалось бы, не должен этого делать.

Давайте разберёмся, почему так получилось.

Так сложилось, что в нашем коллективе добрых, милых и отзывчивых математиков (ДМОиМ) в качестве языка общего назначения используется Ceylon. Будучи отзывчивыми, мы не только используем этот язык, но и участвуем в его развитии, преимущественно багрепортами. С пулреквестами хуже, и первая причина тому: отсутствие в офисе прямого доступа в интернет, только через прокси-сервер. (Нулевая, конечно, нехватка времени.)



Под катом подробности о том, какие именно проблемы возникли при сборке проекта Ceylon из исходного кода и как они были решены. В конце так же несколько слов о её конечной цели.

Оглавление:
Часть 1: Введение и лексический анализ
Часть 2: Реализация парсера и AST
Часть 3: Генерация кода LLVM IR
Часть 4: Добавление JIT и поддержки оптимизатора
Часть 5: Расширение языка: Поток управления
Часть 6: Расширение языка: Операторы, определяемые пользователем
Часть 7: Расширение языка: Изменяемые переменные
Часть 8: Компиляция в объектный код
Часть 9: Добавляем отладочную информацию
Часть 10: Заключение и другие вкусности LLVM

9.1. Заключение

Добро пожаловать в заключительную часть руководства “Создание языка программирования с использованием LLVM”. На протяжении этого руководства, мы вырастили наш маленький язык Калейдоскоп с бесполезной игрушки до довольно интересной (хотя, возможно, по-прежнему бесполезной) игрушки.

Оглавление:

Часть 1: Введение и лексический анализ
Часть 2: Реализация парсера и AST
Часть 3: Генерация кода LLVM IR
Часть 4: Добавление JIT и поддержки оптимизатора
Часть 5: Расширение языка: Поток управления
Часть 6: Расширение языка: Операторы, определяемые пользователем
Часть 7: Расширение языка: Изменяемые переменные
Часть 8: Компиляция в объектный код
Часть 9: Добавляем отладочную информацию
Часть 10: Заключение и другие вкусности LLVM

9.1. Введение

Добро пожаловать в главу 9 руководства “Создание языка программирования с использованием LLVM”. В главах с 1 по 8, мы построили маленький язык программирования с функциями и переменными. Что случится, если что-то пойдёт не так, как тогда отлаживать программу?

Оглавление:
Часть 1: Введение и лексический анализ
Часть 2: Реализация парсера и AST
Часть 3: Генерация кода LLVM IR
Часть 4: Добавление JIT и поддержки оптимизатора
Часть 5: Расширение языка: Поток управления
Часть 6: Расширение языка: Операторы, определяемые пользователем
Часть 7: Расширение языка: Изменяемые переменные
Часть 8: Компиляция в объектный код
Часть 9: Добавляем отладочную информацию
Часть 10: Заключение и другие вкусности LLVM

8.1. Введение

Добро пожаловать в главу 8 руководства “Создание языка программирования с использованием LLVM”. Эта глава описывает, как компилировать программы на нашем языке в объектные файлы.

Это приблизительная расшифровка лекции о предсказании переходов (предсказании ветвлений) на localhost, новом цикле лекций, организованном RC. Выступление состоялось 22 августа 2017 года в Two Sigma Ventures.

Кто из вас использует ветвления в своём коде? Можете поднять руку, если применяете операторы if или сопоставление с образцом?

Большинство присутствующих в аудитории поднимают руки

Сейчас я не буду просить вас подымать руки. Но если я спрошу, сколько из вас думают, что хорошо понимают действия CPU при обработке ветвления и последствия для производительности, и сколько из вас может понять современную научную статью о предсказании ветвлений, то руки подымет меньше людей.

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