C *

Привет, Хабр! В этой статье я хочу рассказать про работу с плавающей точкой для процессоров с архитектурой ARM. Думаю, эта статья будет полезна прежде всего тем, кто портирует свою ОС на ARM-архитектуру и при этом им нужна поддержка аппаратной плавающей точки (что мы и делали для Embox, в котором до этого использовалась программная реализация операций с плавающей точкой).

Итак, приступим.

Указатель ссылается на ячейку памяти, а разыменовать указатель — значит считать значение указываемой ячейки. Значением самого указателя является адрес ячейки памяти. Стандарт языка C не оговаривает форму представления адресов памяти. Это очень важное замечание, поскольку разные архитектуры могут использовать разные модели адресации. Большинство современных архитектур использует линейное адресное пространство или аналогичное ему. Однако даже этот вопрос не оговаривается строго, поскольку адреса могут быть физическими или виртуальными. В некоторых архитектурах используется и вовсе нечисловое представление. Так, Symbolics Lisp Machine оперирует кортежами вида (object, offset) в качестве адресов.

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

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

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

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

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

 

Так, формат 16-разрядных беззнаковых целых при размере такой таблицы около 13 килобайт вмещает всего лишь 6542 простых числа: вслед за числом 65531 идут значения более высокой разрядности. Такая таблица годится разве что в качестве игрушки.

 

Наиболее ходовой в программировании формат 32-разрядных целых выглядит значительно солиднее — он позволяет хранить около 203 млн простых. Но такая таблица занимает уже около 775 мегабайт.

 

Еще больше перспектив у 64-разрядного формата. Однако при теоретической мощности порядка 1e+19 значений, таблица имела бы размер 64 экзабайта.

Недавно один знакомый, которого я знаю через совсем не программистские круги, попросил помочь ему с лабораторной по C++. В коде было примерно следующее:

void do_something(MyObj *input[], int count)
{
    MyObj **copy = new MyObj*[count];
    for (int i = 0; i < count; ++i)
        *copy[i] = *input[i];
    ...
}

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

Лет десять назад на одном форуме была загадана детская, вроде, загадка:

Для чего еду обеда
Людоедоедоеда
Пригласила на обед
Людоедоедовед?

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

Что такое Clang?

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


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

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

Ну или почти вся...

Я считаю, что проблема в современном интернете — это переизбыток информации разного качества. Найти материал по интересующей теме не проблема, проблема отличить хороший материал от плохого, если у вас мало опыта в данной области. Я наблюдаю картину, когда очень много обзорной информации "по верхам" (практически на уровне простого перечисления), очень мало углубленных статей и совсем нет переходных статей от простого к сложному. Тем не менее именно знание особенностей того или иного механизма и позволяет нам сделать осознанный выбор при разработке.

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

Anyone can wield an axe, but it takes a true warrior to make it sing melees melody.

Я предполагаю, что читатель знаком с epoll, по крайней мере прочел страницу man. О epoll, poll, select написано достаточно много, чтобы каждый кто разрабатывал под Linux, хоть раз о нем слышал.

Под катом расположен перевод вступительной части документа Detecting Kernel Memory Disclosure with x86 Emulation and Taint Tracking (Статья Project Zero) от Mateusz Jurczyk.

В переведенной части документа:

• специфика языка программирования C (в рамках проблемы раскрытия памяти)
• специфика работы ядер ОС Windows и Linux (в рамках проблемы раскрытия памяти)
• значимость раскрытия памяти ядра и влияние на безопасность ОС
• существующие методы и техники обнаружения и противодействия раскрытия памяти ядра

Хотя в документе пристально рассматриваются механизмы общения привилегированного ядра ОС с пользовательскими приложениями, суть проблемы можно обощить для любой передачи данных между различными доменами безопасности: гипервизор — гостевая машина, привилегированный системный сервис (демон) — GUI приложение, сетевые клиент — сервер и т.д.

Привет, это уже третья часть из серии моих публикаций, посвящённых обратной разработке «Нейроманта» — видеоигрового воплощения одноимённого романа Уильяма Гибсона.

Реверсим «Нейроманта». Часть 1: Спрайты
Реверсим «Нейроманта». Часть 2: Рендерим шрифт

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

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

В этой статье мы рассмотрим:

• select()
• poll()
• epoll()
• libevent

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


Общий вид реле.

Последнее время среди аксессуаров для велосипедов получили широкое распространение так называемые цифровые велоспидометры (велокомпьютеры). Данные устройства способны измерять множество параметров, главные из которых скорость и расстояние. Принцип измерения скорости основывается на подсчёте периода оборота колеса, а расстояние вычисляется на основе измерения количества таких оборотов. Зачастую датчиком оборота колеса служит геркон в совокупности с магнитом на спице колеса. В зависимости от функциональности, цена таких устройств варьируется в больших пределах. Самый дешёвый велоспидометр можно приобрести примерно за 500 р.

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

Хабр, привет!

Данная статья посвящена разработке I2C (Inter-Integrated Circuit) модуля ядра Linux. Далее описан процесс реализация базовой структуры I2C драйвера, в которую можно легко добавить реализацию необходимого функционала.

Опишем входные данные: I2C блок для нового процессора «зашитый» на ПЛИС, запущенный Linux версии 3.18.19 и периферийные устройства (EEPROM AT24C64 и BME280).

Принцип работы I2C достаточно прост, но если нужно освежить знания, то можно почитать тут.


Рисунок 1. Временная диаграмма сигналов шины I2C

Готовы погрузиться с головой в дивный мир программирования? Хотите узнать как непредсказуемо могут повести себя несколько простых строк кода?

Если ваш ответ "Да!" — добро пожаловать под кат.

Вас будут ждать несколько занимательных задачек на С или С++.

Правильный ответ с объяснением всегда будет спрятан под спойлером.

Удачи!

Дополнено: хорошая дискуссия на Hacker News

Дэвид Ю на GitHub разработал интересный тест производительности для вызовов функций через разные внешние интерфейсы (Foreign Function Interfaces, FFI).

Он создал файл общего объекта (.so) с одной простой функцией C. Затем написал код для многократного вызова этой функции через каждый FFI с измерением времени.

Для C «FFI» он использовал стандартную динамическую компоновку, а не dlopen(). Это различие очень важно, так как действительно сказывается на результатах теста. Можно спорить, насколько честно такое сравнение с фактическим FFI, но всё равно его интересно измерить.

Самый удивительный результат бенчмарка — то, что FFI от LuaJIT существенно быстрее, чем C. Он примерно на 25% быстрее, чем нативный вызов C для функции общего объекта. Как смог слабо и динамически типизированный скриптовый язык обогнать в бенчмарке C? Точен ли результат?

Статья отражает личный опыт автора – заядлого программиста микроконтроллеров, которому после многолетнего опыта микроконтроллерной разработки на языке С (и немного на С++) довелось участвовать в крупном Java-проекте по разработке ПО для ТВ-приставок под управлением Android. В ходе этого проекта удалось собрать заметки об интересных различиях языков Java и C/C++, оценить разные подходы к написанию программ. Статья не претендует на роль справочника, в ней не рассматривается эффективность и производительность Java-программ. Это скорее сборник личных наблюдений. Если не указано иное, то речь идет о версии Java SE 7.

Привет, ты читаешь продолжение статьи, посвящённой реверс-инжинирингу «Нейроманта» — видеоигры, выпущенной компанией Interplay Productions в 1988 году по мотивам одноимённого романа Уильяма Гибсона. И, если ты не видел первую часть, то рекомендую начать с неё, там я рассказываю о своей мотивации и делюсь первыми результатами.

Реверсим «Нейроманта». Часть 1: Спрайты

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

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

Сама задача — получить число 0x17 самым внезапным образом.


Внимание! Данный пост оскорбляет чувство прекрасного и практики программирования на C. Читайте, воспринимайте и комментируйте на свой страх и риск.

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

a = 1
a = a + 1
print(a)

В среде ФП часто критикуют данный момент императивного программирования: «Как так может быть, что a = a + 1? Это всё равно что сказать „1 = 2“. В мутабельном присваивании нет смысла».

Здесь мы наблюдаем несовпадение обозначения: «равно» должно обозначать «равенство», когда на практике оно обозначает «присвоить». Я согласен с этой критикой и считаю, что это неудачная нотация. Но также мне известно, что в некоторых языках вместо a = a + 1 пишут выражение a := a + 1. Почему же эта запись не является нормой?

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

Большая четвёрка

В начале 1960-ых существовало четыре доминирующих высокоуровневых языка: COBOL, FORTRAN II, ALGOL-60, и LISP. В то время, программисты разбивали присваивание на два класса: инициализацию (initialization) — когда вы впервые определяете переменную, и переприсвоение (reassignment) — когда вы вы изменяется значение существующей переменной.

Вашему вниманию предлагается перевод недавнего письма по поводу неоднозначной идеи из рассылки Linux Kernel Mailing List, вызвавшей традиционную реакцию Линуса Торвальдса. Необходимые для понимания пояснения предоставлены в конце поста.

Письмо

Отправитель: Мартин Уэкер
Дата: Tue, 20 Mar 2018 22:13:35 +0000
Тема: Обнаружение целочисленных константных выражений в макросе

Здравствуй Линус,

У меня появилась идея:

Тест для целочисленных константных выражений, который возвращает само целочисленное константное выражение (integer constant expression, ICE), которое должно подходить для передачи в __builtin_choose_expr, и выглядит следующим образом:

#define ICE_P(x) (sizeof(int) == sizeof(*(1 ? ((void*)((x) * 0l)) : (int*)1)))

Кстати, в этом выражении само x не вычисляется в gcc, хотя это и не гарантируется стандартом (я не проверял этот факт в старых версиях gcc.)

Ответ Линуса Торвальдса

Отправитель: Линус Торвальдс <>
Дата: Tue, 20 Mar 2018 16:08:30 -0700
Тема: Re: Обнаружение целочисленных константных выражений в макросе

On Tue, Mar 20, 2018 at 3:13 PM, Мартин Уэкер
<Martin.Uecker@med.uni-goettingen.de> написал:
У меня появилась идея:

Нет, это не «идея».
Это либо работа гения, либо напрочь больного на голову.
До конца пока не уверен, поэтому не могу сказать с точностью.