Ссылка на часть 1

В этой части мы рассмотрим, как AGC организован с точки зрения программиста. Список литературы и источников приведён в конце первой части статьи. Материал этой части основан на материале книги [1].

Представление чисел в памяти AGC

AGC использует 15-битные слова, со знаком в 15-м разряде. Также имеется разряд чётности, который записывается и контролируется аппаратно и полностью прозрачно для программного обеспечения, при каждой операции чтения и записи в память.

Ссылка на часть 2

В предлагаемой вашему вниманию публикации рассмотрены основы архитектуры, аппаратной структуры, и структуры системного ПО бортового компьютера миссий Apollo — AGC (Apollo Guidance Computer). Тем, кто хочет изучить тему подробно, я рекомендую книгу [1] и другие материалы, ссылки на которые приведены в конце статьи.

Apollo Guidance Computer

Setting up Linux on the development board like SocKit with a double-core ARM Cortex A9 is not rocket science. A manufacturer of the board supports the ready-to-use image, appropriate for installing on SD card or another media. But what if you are craving to touch bare metal, approaching a neck-breaking speed of code not restrained by an OS core? Well, it is possible, but not so easy and obvious. In this short essay, I'll give you step-by-step instruction, how to build and run you first bare-metal application on Cyclone V SoC, that uses ARM Cortex A9 core of the HPS subsystem of the SoC.

You need to have the development board with Intel (Altera) Cyclone V SoC. I used SoCKit board:

В этой статье мы рассмотрим, как построить программу на Go, такую, как компилятор или статический анализатор, которая взаимодействует с фреймворком компиляции LLVM, используя язык ассемблера LLVM IR.

TL;DR мы написали библиотеку для взаимодействия с LLVM IR на чистом Go, см. ссылки на код и на пример проекта.

I don’t care what your dragon’s said, it’s a lie. Dragons lie. You don’t know what’s waiting for you on the other side.

Michael Swanwick, The Iron Dragon’s Daughter

This article is based on the post in the Krister Walfridsson’s blog, “Why undefined behavior may call a never called function?”.

The article draws a simple conclusion: undefined behavior in a compiler can do anything, even something absolutely unexpected. In this article, I examine the internal mechanism of this optimization works.

Экосистема TensorFlow содержит ряд компиляторов и оптимизаторов, работающих на различных уровнях программного и аппаратного стека. Для тех, кто использует Tensorflow ежедневно, этот многоуровневый стек может порождать трудные для понимания ошибки, как времени компиляции, так и в рантайме, связанные с использованием разного рода железа (GPU, TPU, мобильных платформ и пр.)

Эти компоненты, начиная с графа Tensorflow, могут быть представлены в виде такой диаграммы:



На самом деле всё сложнее

Фото из коллекции автора

1. История

Пузырьковая память, или память на цилиндрических магнитных доменах является энергонезависимой памятью, разработанной в Bell Labs в 1967 году Эндрю Бобеком (Andrew Bobeck). Исследования показали, что маленькие цилиндрические магнитные домены образуются в монокристаллических тонких плёнках ферритов и гранатов, когда достаточно сильное магнитное поле направлено перпендикулярно поверхности плёнки. Изменяя магнитное поле, можно перемещать эти пузыри. Такие свойства делают магнитные пузырьки идеальным средством для построения последовательного хранилища бит, наподобие сдвигового регистра, в котором наличие или отсутствие пузырька в определённой позиции означает нулевое или единичное значение бита. Диаметр пузыря составляет десятые доли микрона, один чип может хранить тысячи бит данных. Так, например, весной 1977 года Texas Instruments впервые представила на рынке чип ёмкостью 92304 бита. Эта память является энергонезависимой, что делает её похожей на магнитную ленту или диск, но так как она является твердотельной и не содержит движущихся частей, она имеет большую надёжность, чем лента или диск, и не требует обслуживания, а также имеет гораздо меньшие размеры и вес, и может использоваться в портативных устройствах.

C. G. Bell, W. D. Strecker, “Computer What Have We Learned from the PDP-11,” The 3rd Annual Symposium on Computer Architecture Conference Proceedings, pp. l-14, 1976.

Эта статья, которую я выбрал сегодня, является ретроспективой компьютерного дизайна. Это одна из ряда статей Гордона Белла с различными соавторами, описывающей разработку, рост, и внезапную замену культовой линейки продуктов компании, миникомпьютеров PDP-11.

От переводчика: этот пост был опубликован в блоге автора 15 марта 2018 года. Так как язык развивается, в настоящее время его синтаксис может отличаться. Всё описанное относится к Zig 0.2.0, текущая версия языка — Zig 0.3.0.

Я связался с автором поста, и он любезно предоставил ссылку на репозиторий с актуальной версией исходников проекта на Zig 0.3.0

Здравствуйте! Давайте напишем интерпретатор Brainfuck! «Зачем?» — можете спросить вы, но вы не найдёте здесь ответа.

Я сделаю это на Zig.

Zig — это….

…новый язык программирования. Он пока в бета-версии, и быстро развивается. Если вы видели код на Zig раньше, код в этом посте может показаться вам немного другим. Он действительно другой! Zig 0.2.0 только что вышел, совпав с релизом LLVM 6 несколько недель назад, и включает в себя множество изменений синтаксиса и общие усовершенствования языка. Главным образом, многие «заклинания» были заменены ключевыми словами. Смотрите здесь для более глубокого объяснения всех изменений!

Zig разработан, чтобы быть читаемым, и относительно интуитивным для тех, кто знаком с компилируемыми и типизированными языками, такими, как C, C++, и, в некоторых моментах, Rust.

Код был скомпилирован и протестирован с Zig 0.2.0, который доступен прямо сейчас, по различным каналам, включая homebrew, если вы на OSX: brew install zig.

Я планировал написать статью о том, как LLVM оптимизирует функцию, но сначала необходимо написать, как Clang транслирует C или C++ в LLVM.

Проклятие недетерминизма

Моя первая попытка написать проход LLVM — люблю эти сегфолты

Недавно я столкнулся с интересной задачей — мне понадобился детерминированный и кросплатформенный способ определения времени выполнения кода С++. Под словом «детерминированный» я подразумеваю, что один и тот же код будет выполняться за одно и то же количество единиц времени. Под кроссплатформенностью я понимаю, что один и тот же код под Windows и под Ubuntu будет выполняться за одно и то же количество единиц времени.

Естественно, измерение времени на CPU не удовлетворяет этим условиям. Машинный код меняется в зависимости от архитектуры и операционной системы, и один и тот же код займёт различное количество времени при выполнении. Даже на одной и той же машине, такие факторы, как промахи кэша, будут играть большую роль — достаточную для того, чтобы исказить результаты измерения времени выполнения одного и того же кода. Мне нужно было что-либо более умное…

Что такое Clang?

Я провёл последние несколько месяцев, работая с Clang, фронтендом LLVM. Clang умеет парсить и анализировать любой исходный код на языках семейства С (C, C++, ObjectiveC, и т.п....) и имеет удивительную модульную структуру, которая делает его простым в использовании.


Если вы ищете статический анализатор кода, я настоятельно рекомендую Clang, он существенно превосходит другие статические анализаторы (такие, как CIL...) и хорошо документирован. Также список рассылки Clang очень активен и полезен, если вы застряли на чём-то.

Лично я использую Clang для статического анализа драйверов ввода-вывода ядра Linux, включая драйвера камеры и драйвера DRM графической карты. Код ядра, особенно код драйвера, может быть очень сложным и трудным для анализа, но Clang позволяет нам легко поддерживать его. Давайте посмотрим, что можно сделать с его помощью.

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

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

Как я писал в прошлом посте, название моего проекта на GSoC-2016 — «порт RISC-V на Parallella», и первая вещь, которую я должен был сделать, это познакомиться с экосистемой RISC-V. Один из лучших способов это сделать, — посмотреть видео с презентации первого воркшопа RISC-V на Youtube. Для того, чтобы понять самые важные концепции, я рекомендую следующие презентации:

• Введение (Krste Asanović) видео слайды
• Тулчейн RISC-V (Andrew Waterman) видео слайды
• SoC-генератор RISC-V “Rocket Chip” в Chisel (Yunsup Lee) видео слайды
• Структура программного стека RISC-V (Sagar Karandikar) видео слайды
• Отладка на RISC-V (Albert Ou) видео слайды
• Портирование нового кода на RISC-V с OpenEmbedded (Martin Maas) видео слайды
• Окружение тестирования RISC-V (Stephen Twigg) видео слайды

Ещё одна ссылка, если вы интересуетесь Chisel, языком, основанным на Scala, который используется для описания текущей аппаратной реализации ядра RISC-V (ядро Rocket имеет in-order конвейер, BOOM — out-of-order), и любых будущих реализаций.

Краткое руководство по Chisel (Jonathan Bachrach) видео слайды

Работа с Rocket Chip, добавление расширений, инфраструктура ASIC и FPGA (Colin Schmidt) видео слайды

Если вы глубоко заинтересованы в RISC-V и развитии сообщества, я предлагаю вам принять участие в воркшопах.

LLVM 6 уменьшает опасность Spectre, имеет улучшенную поддержку Windows и CPU компании Intel, а также включает WebAssembly в число поддерживаемых целевых платформ.



Инфраструктура компилятора LLVM прошла путь от технически любопытной вещи до живой части современного ландшафта программного обеспечения. Это то ядро, которое стоит за компилятором Clang, за компиляторами языков Rust и Swift, и предоставляет широкие возможности для разработки компиляторов для новых языков.

От переводчика: в статье, которую я предлагаю вашему вниманию, авторы исследовали кодовую базу LLVM/Clang с помощью инструмента анализа кода CppDepend, позволяющего вычислять различные метрики кода и анализировать большие проекты с целью улучшения качества кода.

Время доказало, что Clang является таким же зрелым компилятором C и C++, как GCC и компилятор от Microsoft, но то, что делает его особенным, это то, что это не просто компилятор. Это инфраструктура для создания инструментов. Благодаря тому, что его архитектура основана на использовании библиотек, повторное использование и интеграция функциональности в ваш проект делается более просто и гибко.

От переводчика:
Предлагаю вашему вниманию перевод двух постов из блога John Regehr. Я решил объединить их в одной публикации потому, что, во первых, они имеют небольшой объём, и, во-вторых, второй пост является продолжением первого, и является ответом на комментарий к первому посту на Hacker News.

Ссылка на первый пост
Ссылка на второй пост

Часть 1. Неопределённое поведение != Небезопасное программирование

Неопределённое поведение (UB) в C и C++ представляет собой опасность для разработчиков, особенно если код работает с недоверенными данными. Менее известно, что неопределённое поведение существует в промежуточном представлении (IR) большинства оптимизирующих AOT компиляторов. Например, LLVM IR имеет значение undef и «отравленные» значения в дополнение к взрывоопасному UB языка С. Когда люди начинают беспокоиться об этом, типичная реакция такова: “Что? LLVM IR так же плох, как и C!” Эта статья объясняет, почему считать так неверно.

Представьте себе, что есть некая очень полезная программа, но она, например, существует только в версии Windows и только 64 бита. А вам нужно, например, под ARM64 и под другую ОС, соответственно. Причём исходников у вас нет, и достать их невозможно.


Что делать? Существует проект MCSema (пост на Хабре про mcsema: https://habrahabr.ru/post/232871/). Его создатели (а они на финансировании DARPA, между прочим), обещают сказочные вещи: перевод бинарников в LLVM IR, оптимизации, семантический анализ кода и т.д. И конечно же, перекомпиляцию на любые архитектуры, которые поддерживает LLVM. Проект опенсорсный (ссылка на гитхаб: https://github.com/trailofbits/mcsema)

А теперь посмотрим, что происходит на самом деле.

Продолжение. Начало здесь.

Введение

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

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