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

Продолжение статьи, где удалось продемонстрировать, что фронтенд стековой машины вполне позволяет спрятать за ним суперскалярный процессор с OoO.
Тема данной статьи — вызов функций.

От переводчика: данная статья является пятой в цикле переводов официального руководства по библиотеке SFML. Прошлую статью можно найти тут. Данный цикл статей ставит своей целью предоставить людям, не знающим язык оригинала, возможность ознакомится с этой библиотекой. SFML — это простая и кроссплатформенная мультимедиа библиотека. SFML обеспечивает простой интерфейс для разработки игр и прочих мультимедийных приложений. Оригинальную статью можно найти тут. Начнем.

От переводчика: данная статья является второй в цикле переводов официального руководства по библиотеке SFML. Прошлую статью можно найти тут. Данный цикл статей ставит своей целью предоставить людям, не знающим язык оригинала, возможность ознакомится с этой библиотекой. SFML — это простая и кроссплатформенная мультимедиа библиотека. SFML обеспечивает простой интерфейс для разработки игр и прочих мультимедийных приложений. Оригинальную статью можно найти тут. Начнем.

В данной статье мы будем разрабатывать (программную) модель суперскалярного процессора с OOO и фронтендом стековой машины.

В нашем проекте PT Application Inspector реализовано несколько подходов к анализу исходного кода на различных языках программирования:

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

Наш цикл статей посвящен структуре и принципам работы модуля сигнатурного поиска (PM, pattern matching). Преимущества такого анализатора — скорость работы, простота описания шаблонов и масштабируемость на другие языки. Среди недостатков можно выделить то, что модуль не в состоянии анализировать сложные уязвимости, требующие построения высокоуровневых моделей выполнения кода.

К разрабатываемому модулю были, в числе прочих, сформулированы следующие требования:

• поддержка нескольких языков программирования и простое добавление новых;
• поддержка анализа кода, содержащего синтаксические и семантические ошибки;
• возможность описания шаблонов на универсальном языке (DSL, domain specific language).

В нашем случае все шаблоны описывают какие-либо уязвимости или недостатки в исходном коде.

Весь процесс анализа кода может быть разбит на следующие этапы:

1. парсинг в зависимое от языка представление (abstract syntax tree, AST);
2. преобразование AST в независимый от языка унифицированный формат;
3. непосредственное сопоставление с шаблонами, описанными на DSL.

Данная статья посвящена первому этапу, а именно: парсингу, сравнению функциональных возможностей и особенностей различных парсеров, применению теории на практике на примере грамматик Java, PHP, PLSQL, TSQL и даже C#. Остальные этапы будут рассмотрены в следующих публикациях.

«Она истинный морпех, но если копнуть глубже, мы найдем пирата.»



Грейс Хоппер (Grace Hopper) — американская учёная и контр-адмирал флота США. Программист гарвардского компьютера Марк I.

• В детстве разобрала 7 будильников, чтобы понять, как все устроено.
• Боролась за идею машинонезависимого языка программирования.
• Разработала первый компилятор.
• Приложила руку к распространению мема «дебаггинг» (выловив настоящего жука из Mark 2).
• Могла объяснить сообразительным военным, что такое «наносекунда» и «пикосекунда». На пальцах.
• В её честь назвали эсминец USS Hopper (DDG-70).
• И суперкомпьютер Cray XE6 «Hopper».
• И в ее честь именная премия Ассоциации вычислительной техники (ACM) — присуждается молодому (до 35 лет) специалисту, сделавшему значительный вклад в области вычислительной техники.

Построив успешную карьеру математика в Йеле (защитив докторскую и став профессором), Грэйс Хоппер в 1943 (37 лет) пошла добровольцем во Флот.
Но у нее был недобор по весу 6 кг, поэтому пришлось сесть «за клавиатуру» Гарвардского Mark 1.

ОС Фантом — экспериментальная операционная система, содержащая на прикладном уровне виртуальную байткод-машину в персистентной оперативной памяти.

Один из двух ключевых запланированных для ОС Фантом путей миграции существующего кода — преобразование байткода Java в байткод Фантом.

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

Обе машины — стековые. Обе оперируют двумя отдельными стеками — стеком для работы с объектами (на стеке лежат только ссылки), и бинарным стеком — для вычислений. Машина Фантома имеет также отдельные стеки для фреймов функций и ловушек исключений. Как эта часть устроена в JVM, я не знаю до сих пор, но полагаю, что вряд ли кардинально отличным образом.

Естественно, что и набор операций стековых машин местами схож как две капли.

Но, безусловно, есть и весьма существенные отличия.

Представим себе, что в один прекрасный день вам пришла в голову идея процессора собственной, ни на что не похожей архитектуры, и вам очень захотелось эту идею реализовать «в железе». К счастью, в этом нет ничего невозможного. Немного верилога, и вот ваша идея реализована. Вам уже снятся прекрасные сны про то, как Intel разорилась, Microsoft спешно переписывает Windows под вашу архитектуру, а Linux-сообщество уже написало под ваш микропроцессор свежую версию системы с весьма нескучными обоями.
Однако, для всего этого не хватает одной мелочи: компилятора!
Да, я знаю, что многие не считают наличие компилятора чем-то важным, считая, что все должны программировать строго на ассемблере. Если вы тоже так считаете, я не буду с вами спорить, просто не читайте дальше.
Если вы хотите, чтобы для вашей оригинальной архитектуры был доступен хотя бы язык С, прошу под кат.
В статье будет рассматриваться применение инфраструктуры компиляторов LLVM для построения собственных решений на её основе.
Область применения LLVM не ограничивается разработкой компиляторов для новых процессоров, инфраструктура компиляторов LLVM также может применяться для разработки компиляторов новых языков программирования, новых алгоритмов оптимизации и специфических инструментов статического анализа программного кода (поиск ошибок, сбор статистики и т.п.).
Например, вы можете использовать какой-то стандартный процессор (например, ARM) в сочетании с специализированным сопроцессором (например, матричный FPU), в этом случае вам может понадобиться модифицировать существующий компилятор для ARM так, чтобы он мог генерировать код для вашего FPU.
Также интересным применением LLVM может быть генерация исходных текстов на языке высокого уровня («перевод» с одного языка на другой). Например, можно написать генератор кода на Verilog по исходному коду на С.



КДПВ

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

На практике далеко не всегда предупреждения компилятора одинаково полезны. Зачастую они не помогают разработчикам, а мешают им и могут провоцировать на исправление совершенно правильного кода, т.е. на нарушение правила «работает — не трогай».

Jack (Java Android Compiler Kit) – это компилятор, преобразующий исходный код на Java в DEX-файлы Android. Jack – это набор инструментов, среди его возможностей – переупаковка, сжатие, обфускация и поддержка множественных DEX-файлов.

В Jack используются промежуточные библиотеки в формате .jack. Преобразованием существующих .aar/.jar файлов в этот формат занимается Jill (Jack Intermediate Library Linker).



Если для сборки используется Jack, то сначала Jill конвертирует внешние библиотеки, используемые в проекте, в .jack-файлы. Это подготавливает библиотеки к быстрому слиянию с другими .jack-файлами на следующем этапе, когда Jack и плагин Android Gradle, используя подготовленные ранее.jack-файлы и исходный Java-код, компилируют DEX-файл (или файлы). В ходе этого процесса Jack может выполнить минификацию кода (сжатие, обфускацию, или и то и другое вместе). На выходе получается APK-файл Android-приложения.

Несколько недель назад я наткнулся на сравнительный анализ Rust, D и Go от Андрея Александреску. Андрей, уважаемый член сообщества C++ и главный разработчик языка программирования D, нанес Rust сокрушительный удар под конец своего повествования, высказав нечто, что выглядит довольно проницательным наблюдением:

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

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

2015 год был значительным годом для Rust: мы выпустили версию 1.0, стабилизировали большинство элементов языка и кучу библиотек, значительно выросли как сообщество, а также реорганизовали управление проектом. Может показаться что 2016 год не будет таким же интересным (будет трудно превзойти выпуск 1.0), но это будет супер-важный год для Rust, в котором произойдет много захватывающих вещей. В этой статье я расскажу о том, что, как я думаю, должно произойти. Это не официальная позиция и не обещание разработчиков Rust.

2015

Прежде чем мы поговорим о будущем, вот несколько цифр за прошлый год:

В 2015 году силами сообщества Rust:

• Создано 331 предложение по улучшению языка (RFC)
  • из которых 161 было принято и влито в основной репозиторий
  • всего 120 человек подало RFC, из них 6 человек создало 10 и более, Alex Crichton создал 23 RFC
• Создано 559 задач по улучшению RFC
• Прислано и влито в репозиторий Rust 4630 Pull-запросов
  • авторами которых является 831 человек, из них 91 создали больше 10 запросов, 446 человек создали только один, а Steve Klabnik был автором 551 pull-запроса
• Создано 4710 задач
  • из которых 1611 еще открыты
  • авторами которых является 1319 человек, из которых 79 создали больше 10, а Alex Crichton открыл всего 159 задач
• Выпущено шесть стабильных релизов Rust (1.0 – 1.5)
• Поддерживается стабильность Rust – 96% пакетов, которые компилировались на 1.0, по прежнему компилируются с использованием версии 1.5

Предлагаю вам перевод дневника Руи Уэяма (Rui Ueyama), программиста из Google, который он вел во время работы над реализацией компилятора языка C около трех с половиной лет назад (но опубликовал только в минувшем декабре).
Этот дневник не несет какой-то практической пользы и не является туториалом, но мне было очень интересно его прочитать, надеюсь и вам эта история тоже понравится :)

Я написал C компилятор за 40 дней, который назвал 8cc. Это дневник написанный мной в то время. Код и его историю можно посмотреть на GitHub.

Возможно, я скажу банальную вещь, но прошедший год был хорошим годом для С++!

Просто факты:

• Вышла Visual Studio 2015 с отличной поддержкой возможностей С++14/17 и даже нескольких экспериментальных вещей
• Вышел долгожданный GCC 5.0
• С++ набрал серьёзную популярность. Где-то с июля — третье место в Tiobe Ranking
• На конференции CppCon 2015 было сделано несколько важных анонсов

А теперь об этом и другом немного подробнее

От переводчика

Процедурные макросы — одна из наиболее ожидаемых фич Rust. На данный момент процедурные макросы возможно писать только под нестабильную версию компилятора, хотя есть несколько контейнеров, вроде syntex, позволяющие делать ограниченную кодогенерацию в рамках стабильного компилятора. Однако ситуацию это особо не облегчает, поскольку интерфейс к AST остаётся нестабильным, и, хотя авторы syntex стараются идти в ногу с ночными сборками, иногда случаются фейлы из-за изменений в структуре AST.
В этом блог посте один из участников core team — Nick Cameron — поделился своим видением будущего процедурных макросов. Хотя пост полон технических подробностей по внутренностям компилятора, мне показалось, что хабрасообществу может быть интересно заглянуть немного за кулисы разработки Rust.

Фреймворк для процедурных макросов

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

WebAssembly — это новый бинарный формат, в который могут быть скомпилированы веб-приложения. Он проектируется и реализуется прямо в тот момент, когда вы читаете эти строки и двигают его вперёд разработчики всех основных браузеров. Всё меняется очень быстро! В этой статье мы покажем текущее состояние проекта с достаточно глубоким погружением в инструментарий по работе с WebAssembly.

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

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

Совсем недавно компания Intel выпустила очень интересный набор инструментов для разработчиков программного обеспечения, позволяющий добавить защиту программного кода от взлома и существенно усложнить жизнь взломщикам программ. Этот набор включает в себя обфусцирующий компилятор, средство для создания файла подписи, используемого для проверки целостности загружаемых динамических библиотек, а также библиотеку функций проверки целостности и дополнительные полезные инструменты. Intel® Tamper Protection Toolkit beta можно совершенно бесплатно скачать на сайте Intel.

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

Программирующая Программа — первый компилятор

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

Это 6-я статья цикла по разработке, управляемой моделями. В прошлой статье вы получили общее представление о разработке предметно-ориентированных языков с помощью EMFText. Настало время перейти от игрушечного языка к более серьёзному. Будет очень много рисунков, кода и текста. Если вы планируете использовать EMFText или подобный инструмент, то эта статья должна сэкономить вам много времени. Возможно, вы узнаете что-то новое о EMF (делегаты преобразований).

Подобно отважному хоббиту мы начнём свой путь с BNF-грамматики SQL, дойдём до жуткого дракона (метамодели) и вернёмся обратно к грамматике, но уже другой…

Прим. переводчика: Это перевод статьи Питера Брайта (Peter Bright) «How security flaws work: The buffer overflow» о том, как работает переполнение буфера и как развивались уязвимости и методы защиты.

Беря своё начало с Червя Морриса (Morris Worm) 1988 года, эта проблема поразила всех, и Linux, и Windows.



Переполнение буфера (buffer overflow) давно известно в области компьютерной безопасности. Даже первый само-распространяющийся Интернет-червь — Червь Морриса 1988 года — использовал переполнение буфера в Unix-демоне finger для распространения между машинами. Двадцать семь лет спустя, переполнение буфера остаётся источником проблем. Разработчики Windows изменили свой подход к безопасности после двух основанных на переполнении буфера эксплойтов в начале двухтысячных. А обнаруженное в мае сего года переполнение буфера в Linux драйвере (потенциально) подставляет под удар миллионы домашних и SMB маршрутизаторов.

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

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