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

Представьте, что вы читаете громкий заголовок: «Самая простая Turing‑complete архитектура SUBLEQ (всего одна инструкция!) и реализовали её на фотонных логических вентилях». Звучит как настоящий прорыв из научной фантастики — один‑единственный тип команды, и вот уже у нас полноценный универсальный компьютер, работающий на скорости света, без кремния, без транзисторов, с терагерцевыми частотами и энергопотреблением в разы ниже.

Но если копнуть глубже, сразу вылезают два больших «но». Первое — SUBLEQ действительно может быть Turing‑полной, но только при очень конкретных условиях. Второе — реализовать даже такую «простую» архитектуру на настоящих фотонных вентилях в железе оказывается совсем не тривиальной задачей. И именно об этом мы сегодня поговорим подробно, без хайпа, но и без излишнего скепсиса.

Эта статья — разбор реальной истории, которая происходит прямо сейчас, в 2026 году. Немецкий стартап Akhetonics из Мюнхена всерьёз взялся за all‑optical general‑purpose processor и выбрал для доказательства концепции именно SUBLEQ. Мы пройдёмся по всем нюансам: от теории одной инструкции до проблем фотонной памяти, от лабораторных прототипов до того, почему чистый SUBLEQ, скорее всего, останется красивым PoC, а в реальном продукте придётся расширять набор команд.

Готовы? Поехали.

Я занимаюсь разработкой компиляторов, то есть, пишу программы, преобразующие программы в программы. Иногда требуется нацелиться на более высокоуровневый язык, чем, скажем, простой ассемблер, и зачастую именно в таком качестве удобно взять язык C. Генерировать C не так страшно как писать от руки — в частности, потому, что генератор умеет не попадать в ловушки, связанные с неопределённым поведением. А когда пишешь на C вручную, именно неопределённого поведения следует особенно остерегаться. Здесь я опишу некоторые паттерны, которые обнаружил сам, и которые помогают мне результативно работать.

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

Признаюсь, я питаю слабость к классическому DOOM. Игре уже 31 год, но благодаря открытому исходному коду она живёт на всём — от смартфонов до осциллографов. В силу разных обстоятельств я стал сопровождать несколько пакетов, связанных с DOOM, в Fedora Linux.

Перед каждым релизом Fedora проводит массовую пересборку всех пакетов — и в этот раз chocolate-doom её не пережил. Виновник этому — маленький bool.

Язык активно улучшается, осталось недолго до bootstrapping'а! Также уменя есть планы писать LSP и загрузить язык на github linguist. Для последнего нужны репозитории (>200). Для тех, кому нечего делать, или кому просто не лень, попробуйте пописать программки на моем языке. Пока мало что можно будет написать, но, думаю, хотя бы что-то можно.

Первые исполняемые файлы Quake (quake.exe и vquake.exe) программировали на HP 712-60 с NeXT и кросс-компилировали при помощи DJGPP, запущенного на DEC Alpha server 2100A. В июне 1996 года, после выпуска игры, id Software, озабоченная стагнацией NeXT, решила поменять стек разработки.

Сразу после выпуска Quake мы перешли на оборудование Intergraph с Windows NT.

- Джон Кармак^[1]

Следующие версии Quake (winquake.exe, glquake.exe) и QuakeWorld (qwcl.exe и qwsv.exe) разработаны и скомпилированы в Windows NT с помощью Visual C++ 4.X.

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

Эта статья посвящена языку программирования Go 1.24, работающему на Linux на архитектуре ARM. Она может не охватывать специфические для других операционных систем (ОС) или аппаратных архитектур детали.

В этой статье подробно рассматриваются следующие вопросы:

Компиляция и среда выполнения Go
Примитивный планировщик
Улучшение планировщика
Модель GMP
Начальная загрузка программы
Создание горутины
Цикл планирования
Поиск готовой к выполнения горутины
Вытеснение горутин
Обработка системных вызовов
Сетевой и файловый ввод-вывод
Работа netpoll
Сборщик мусора
Общие функции
API среды выполнения Go

Зачем вообще компилировать TypeScript?

Есть большой проект, с кодовой базой в два миллиона строк на C++. Ядро на плюсах, поверх него работают несколько UI: десктопный интерфейс, веб и мобильное приложение. В какой-то момент проект упирается сразу в две проблемы. Первая — лицензионные ограничения: новые версии Qt, на которых мог бы жить десктопный интерфейс, становятся недоступны по санкционным причинам. Вторая — скорость разработки: UI давно хотелось писать быстрее.

Возникает логичный вопрос: что, если взять лучшие, максимально автоматизированные инструменты из веба и перенести их в мир нативных приложений без браузера и лишних прослоек? Ключевая цель — обеспечить возможность вызова C++-код из TypeScript с возвратом результата без промежуточных интерпретаторов.

Меня зовут Владимир Цышнатий @Tsyshnatiy. Я занимаюсь разработкой более 15 лет, мой основной профиль — C++. Помимо этого меня увлекают технологии на стыке разных миров. В том числе идея, лежащая в основе этой статьи: дать возможность писать на TS как на нативном языке.

Интересно узнать, как мы это делали и что получилось? Детали под катом! 

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

GitHub

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

Универсальный компилятор для FPGA, который понимает 42 языка программирования

Пишите код на любимом языке — получайте работающий Verilog для FPGA. Бесплатно, без vendor lock-in.

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

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

$ rustup update stable

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

Если вы хотите помочь нам протестировать будущие выпуски, вы можете использовать канал beta (rustup default beta) или nightly (rustup default nightly). Пожалуйста, сообщайте обо всех встреченных вами ошибках.

Markdown — популярный и удобный язык разметки, но это также и очень ограниченный формат. Поэтому задача написания в Markdown сложной технической документации по ГОСТ, научной статьи с автоматической настройкой оформления для заданного издательства или хорошо оформленного онлайн-учебника может показаться неосуществимой. В этой статье рассмотрим способ работы над научно-техническими статьями и книгами в формате Markdown на основе подхода Docs as Code с учётом строгих ограничений на оформление, используемый Петром Советовым и мной при подготовке учебных материалов в РТУ МИРЭА.

Способ заключается в применении утилиты pandoc для построения дерева абстрактного синтаксиса (AST) Markdown-документа с последующим переписыванием AST набором фильтров на Lua и трансляцией AST в форматы docx и pdf, соответствующие ГОСТ, а также в диалект markdown, совместимый с mdBook, для генерации онлайн-учебника.

Онлайн-версии книг, написанных с использованием описанного подхода, и репозитории с исходным кодом книг опубликованы на GitHub и GitHub Pages: книга по конфигурационному управлению, книга по разработке кроссплатформенных программмных систем.

В данной статье были проведены запуски JIT-бенчмарков под двоичными трансляторами из x86 в ARM Microsoft Prism Emulator, Apple Rosetta 2 и FEX Emulator. Также была проведена оценка влияния динамических модификаций кода на производительность двоичной трансляции.

GitHub

Onyx — язык программирования, нацеленный на базовую безопасность памяти, приятный синтаксис и опыт использования. Onyx написан на C++ с компиляцией на базе LLVM. На момент написания статьи язык поддерживает:

Привет, Хабр! Меня зовут Пётр Чекмарёв, я старший инженер компании YADRO, занимаюсь компьютерным зрением на мобильных устройствах и низкоуровневой оптимизацией плотных вычислительных функций.

Оптимизация кода — вечная тема, особенно актуальная в дни триумфального шествия искусственного интеллекта. Оптимально написанные, но изолированные ядра сетей составляются в разные последовательности в зависимости от архитектуры модели. Но, если дать им информацию друг о друге во время компиляции, сеть удастся заметно ускорить. Выгружать программу для перекомпиляции, будь она движком инференса или СУБД ,— бессмысленно, поэтому компилировать надо во время работы, Just-In-Time. Я расскажу про свой пет-проект векторной JIT-кодогенерации и покажу, как она помогает в оптимизации.

Разработка собственных языков и языковых серверов может быть сложной и рутинной задачей. Langium — инструмент на TypeScript, который упрощает создание предметно‑ориентированных языков (DSL) с готовым LSP‑сервером.

Меня зовут Денис Маматин, я работаю в R&D‑отделе СберТеха. В ходе разработки одного из наших проектов мы столкнулись с необходимостью создания собственного DSL, и в этом нам существенно помог Langium. В этой статье я рассмотрю, как устроена грамматика Langium, как создать первый проект и какие преимущества он даёт разработчику.

Проблема: когда из-за «оптимизации» код замедляется

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

В данной статье я попытаюсь переписать часть приложения Kawai-Focus на стек: FastAPI + Vue.js + Tauri + Ionic. Также я соберу приложение только с экраном «Таймеры» под Linux в AppImage, которое подойдёт для большинства Linux-дистрибутивов. Реализация одного экрана не будет слишком долгим процессом, а финальная сборка приложения позволит оценить сложность и удобство полного цикла разработки.

Эта cтатья не будет подробным гайдом, так как размер переписанного кода и его описание слишком велики для одной статьи. Однако я покажу часть кода проекта и расскажу о выбранном стеке, а также о трудностях и преимуществах, с которыми я столкнулся в процессе переписывания проекта. Я буду использовать часть кода старого проекта, который не касается Kivy и KivyMD, поэтому его душа не умрёт, а обновится.

Заваривайте чай, доставайте вкусняшки — пора «старый стек превращать в удобрение для новых помидор»! 🍅

Продолжение статьи о разработке стекового процессора с оригинальной архитектурой.
Здесь мы занимаемся инфраструктурой - ассемблером, компилятором С и эмулятором процессора.

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

Эту фразу из «Макбета» Шекспира автор осмелится перевести как «благодаря зуду на кончиках моих пальцев может появиться что‑то очень странное».

Изначально хотелось всего‑лишь ознакомиться с Verilog, но, «опасное это дело, выходить за порог: стоит ступить на дорогу и, если дашь волю ногам, неизвестно куда тебя занесет».

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

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