C *

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

В подавляющем большинстве компьютерных систем для работы с некоторой ячейкой памяти необходимо как-то указать ее адрес, как правило 16-, 32- или 64-разрядное число. Количество бит в адресе часто называют разряностью системы. Часто дополнительно используется механизм "трансляции страниц", который отображает области виртуальной памяти пользовательского приложения в физическую память, которой управляет операционная система. Но в каждый момент времени активна отлько одна "таблица страниц" и с точки зрения приложения (а во многом и с точки зрения ядра ОС) память остается плоской.

Рассмотрим старый процессор Intel 86/88/186. Размер регистров этих процессоров всего 16 бит, что позволяет адресовать всего 64 килобайта памяти. Когда эти микросхемы разрабатывались, такого размера памяти уже не хватало для многих приложений, а 32-разрядные процессора были слишком дороги. Проблему решили добавив в архитекруту сегментные регистры. При обращении к памяти к 16-битному адресу (хранящемуся в реристре общего назначения или прямо в коде команды) прибавлялось значение сегментного регистра, сдвинутое на 4 бита (что тоже самое, умноженное на 16) и полученное значение использовалось как физический адрес. Такой подход позволял адресовать до одного гигабайта памяти. В архитектуре персональных компьтерах IBM PC, созданных на базе этих процессров, часть адресного пространства было зарезервировано для системных нужд, а пользовательским приложениям и ОС было доступно до 640 килобайт. Но не все так просто.

В предыдущих сериях:

• Go быстрее Rust, Mail.Ru Group сделала замеры
• C++ быстрее и безопаснее Rust, Yandex сделала замеры

Медленно, но верно Раст проникает не только в умы сотрудников больших корпораций, но и в умы школьников и студентов. В этот раз мы поговорим о статье от студента МГУ: https://rustmustdie.com/.

Её репостнул Андрей Викторович Столяров, доцент кафедры алгоритмических языков факультета ВМК МГУ им. М. В. Ломоносова и по совместительству научрук студента-автора статьи.

Я бы сказал, что тут дело даже не в том, что он "неинтуитивный". Дело скорее в том, что компилятор раста сам решает, когда владение "должно" (с его, компилятора, точки зрения) перейти от одного игрока к другому. А решать это вообще-то должен программист, а не компилятор. Ну и начинается пляска вида "как заставить тупой компайлер сделать то, чего я хочу".
Бред это всё.

— А. В. Столяров

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

То есть перечислить самые универсальные и переносимые программные компоненты (кирпичики), которые могут пригодиться в практически любой сборке.

В предыдущей статье блога мы обсудили краткую историю системного вызова select(2). В ней делается вывод, что для эмуляции консолей, игр и нетривиальных TCP/IP-приложений было необходимо определенное мультиплексирование ввода-вывода.

Разработчики BSD (Berkeley Software Distribution) выбрали модель мультиплексирования select, и за ними последовали другие Unix-подобные системы. Но является ли select единственной моделью мультиплексирования?

Тема эта стала неинтересной, всё то же и так же из раза в раз

Сеньоры начинают и проигрывают пенсионерам.

Это уже третий раз и должны уже наверно свыкнуться. ))

FizzBuzz по-сениорски

FizzBuzz по-пенсионерски

Продолжаем разгонять FizzBuzz

FizzBuzz по-македонски

Немного лирики. Хабр из места, где пишут в стиле "смотрите коллеги, можно и так ..." превратился в место хвастовства и рекламы. Пенсионеры хорошо знают, что невозможно написать код, который нельзя улучшить. И реальные сеньоры только рады, когда им пишешь про то, как можно улучшить их код. Я проверял ))

Разработка современного софта это далеко не только про код.

Разработка современного софта это во многом про ToolСhain(ы). Прежде чем начать исполняться исходники проходят гигантский путь. C каждым поколением выходят все более и более массивные системы сборки.
Современные технологии разработки софта это многостадийные конвейеры из различных утилит. Понять их весьма сложно, но можно. А поможет нам в этом хипстерский язык программирования Dot.

Гидроакустическая станция серийная, Echologger MRS-900. Однолучевая, луч сканирует по кругу или в секторе. Штатное программное обеспечение есть, работает под Windows. От меня потребовалась версия под Linux.

В этом посте я расскажу о некоторых уловках, которыми я воспользовалась, чтобы уменьшить двоичные файлы С/С++/Python с помощью ассемблера для x86. Здесь всё крутится вокруг кодовой базы Cosmopolitan. Дело в том, что из недавнего отзыва по проекту ELKS я узнала, что мой код там всем понравился и они хотят узнать больше о том, что трюки cosmo могут дать проектам вроде «Linux-порта i8086». Я почувствовала, что мы с ребятами проекта ELKS «одной крови», ведь первое, что я написала при создании Cosmopolitan, — это загрузчик i8086, который назывался Actually Portable Executable. А ещё мне было приятно узнать, что людям, которые погрузились в эту проблему гораздо раньше меня, нравятся мои наработки в Cosmopolitan. И тогда я решила, что неплохо было бы поделиться ими с более широкой аудиторией.

В своей предыдущей статье я упомянул Hebron - утилиту для портирования кода с C на C# или на Rust.

В этой статье хотелось бы подробно расписать - как я с ней работаю.

Написанное можно воспринимать как своего рода мануал на тот случай, если кто-нибудь тоже захочет что-нибудь портануть.

Итак, портирование осуществляется в 4 шага:

В этой статье я бы хотел рассказать о своем хобби проекте под названием StbSharp.

Итак, в 2016 году мне пришла в голову весьма банальная идея - сделать собственный игровой кросс-платформенный движок на C#. И я озаботился поиском кросс-платформенной же библиотеки для загрузки картинок. Внезапно выяснилось, что подходящей просто не существовало. Было множество платформо-зависимых решений(напр. System.Drawing). А так же имелась SixLabors.ImageSharp. Но она была в состоянии ранней альфы. Мне же хотелось работать с решением, проверенным временем. Так я пришёл к идее портировать stb_image.h (очень популярной в геймдеве single-header библиотеки для загрузки картинок) на C#.

"А разве не легче было написать биндинги для нативной библиотеки? Хоть для той же stb_image?",- задаст справедливый вопрос читатель. Да, легче. И правильнее. О чём, собственно, и говорит заголовок этой статьи. Конечно, использование биндингов доставляет некоторые неудобства в плане того, что необходимо доставить соответствующий нативный бинарник на устройство конечного пользователя. Однако эти неудобства с лихвой окупаются достоинствами. А именно лучшим перформансом и портируемостью.

Однако, проект показался мне столь интересным, что я проигнорировал эти справедливые возражения.

Long story short

Сеньоры начинают и проигрывают

Тут как на олимпийских играх - быстрее, короче, изящней.

В продолжение увлекательной дискуссии

FizzBuzz по-сениорски

FizzBuzz по-пенсионерски

Продолжаем разгонять FizzBuzz

PostgreSQL — это мощная система управления реляционными базами данных с открытым исходным кодом. Она дополняет язык SQL новыми фичами. СУБД определяется не только ее производительностью и встроенными фичами, но и способностью поддерживать персонализированную/дополнительную, специфичную для пользователя функциональность. Некоторые из этих возможностей могут быть представлены в виде конструкций или модулей базы данных, таких как хранимые процедуры или функции, но их объем обычно ограничен функциональностью, предоставляемой СУБД. Например, как вы напишете кастомное приложение для анализа запросов, которое будет находиться внутри вашей СУБД?

Представим: сервер может отправлять легитимные запросы, но IP, на которые он будет их слать, неизвестны. В журнале сетевого фильтра видно что запросы таки да, идут. Но не ясно - это как раз легитимные или информация уже утекает к злоумышленникам? Было бы проще если бы был известен домен на который сервер посылает данные. Увы, но PTR не в моде, а securitytrails показывает или ничего, или слишком много по этому IP.

Можно запустить tcpdump. Но кто захочет постоянно смотреть в монитор? А если сервер не один? Есть packetbeat. Это чудовище, которое выжрало процессор на всех серверах. Брр… Не хочу о нём вспоминать. Osquery - неплохой инструмент который многое знает о сетевых подключениях и ничего - о DNS-запросах. Соответствующее предложение было просто закрыто. Zeek - о нём я узнал когда начал искать как отслеживать DNS-запросы. Похоже он неплох, но меня смутило два момента: он следит не только за DNS, а значит ресурсы будут тратиться на работу результат которой мне не нужен (хотя, возможно, в настройках можно выбрать протоколы); а ещё он ничего не знает о том какой процесс послал запрос.

Неужели это всё? Я вроде бы что-то слышал про eBPF…

В программировании микроконтроллеров часто приходится писать драйверы периферийных микросхем. Зачастую это 60% всего кода большинства проектов. В этом тексте я написал несколько общих нюансов разработки драйверов периферийных чипов.

Хочу рассказать о том, как занимался оптимизацией card raytracer - минимального рейтрейсера, код которого умещается на визитке.

Точнее, это развёрнутая для лучшей читабельности версия, которая в форумной ветке
использовалась как тест скорости разных языков.

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

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

Наверное, статья в большей степени полезна новичкам, но и опытные разработчики (по привычке с 2000-го года пишущие SIMD-код интринсиками) могут найти что-то новое.

Компилятор - в основном Clang, можно GCC, в конечном итоге я адаптировал и под MSVC.

C и C++ программисты в какой-то момент могут столкнуться с ограниченным размером PATH_MAX и задаться вопросом – какого размера создавать буфер, чтобы отследить путь к директориям или файлам?

Данное руководство позволит читателю составить полную картину того, как организовать сборку C++ библиотек с использованием современных возможностей CMake. Предполагается, что читатель имеет представление о базовых понятиях из мира CMake и динамических/статических C++ библиотек, так как в руководстве они могут не объясняться.

Механизм структурированной обработки исключений (Structured Exception Handling, SEH) позволяет не только "отловить" сгенерированное исключение, но и вернуться к инструкции, вызвавшей сбой и попробовать выполнить ее заново.

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

Знакомая картинка? Думаю, что знакома она многим. Дети 90-х (ух, что тогда творилось, в песне Монеточки это всё описано), видели этот логотип при старте приставки PS1. И оказалось, что