Comments 10
Бред какой-то...
Если речь о высокоуровневых оптимизациях, таких как формы
SSA(Static Single Assignment), то на уровне ассемблера они просто неуместны.
SSA - это не оптимизация, а просто популярная форма IR.
А вообще, у меня складывается ощущение, что это какой-то троллинг. Трудно поверить, чтобы кто-то это все делал всерьез. Например, какой смысл уделять время такой нерелавантой тут вещи, как парсер командной строки, зачем тут генерация deb пакета и тд? Это все такое вторичное в контексте проекта компилятора.
Ну и наконец зачем делать сотни пустых коммитов в репозитории:)
"Вторичные" фичи? Не совсем!
Я понимаю, почему такие элементы, как парсер командной строки или генерация .deb пакетов, могут показаться второстепенными в классическом понимании компилятора, основная задача которого — трансляция кода. Однако проект AsmX ставит перед собой более широкую цель — переосмыслить, чем может быть компилятор в 2025 году.
Парсер TAPI: Это не просто CLI для галочки. Улучшенный парсер в
v29-rev1.0делает команды вродеasmx main.asmx --release -o mymain --package --package-type debинтуитивными. Это экономит время, особенно если ты в CI/CD или пишешь скрипты. Без удобного интерфейса компилятор был бы как спортивная тачка без руля — мощная, но неудобная. Хороший ключевой элемент юзабилити..deb-пакеты: Генерация пакетов (
.deb) — это шаг к инновационной концепции "пакетного компилятора". Назови это "пакетным компилятором", если хочешь! Генерация.deb— это не мелочь, а способ сразу превратить твой код в приложение, готовое к установке на Ubuntu или Debian. Помогает готовить его к немедленной дистрибуции и интеграции в операционную систему. Представь: ты пишешь код, запускаешь одну команду, и бам — твой бинарник уже в пакете, который можно закинуть на миллионы систем. Это реально упрощает жизнь.AUR-пакеты: Мы недавно добавили в AUR не только
asmx-g3-git, но иasmx-stableдля тех, кто хочет надёжности, иasmx-officialдля продакшена. Это не просто для Arch-фанатов — это про то, как сделать AsmX доступным каждому, кто любитyay -S.
Эти "мелочи" — не отвлечение, а способ сделать AsmX полезным в реальных сценариях, от хобби-проектов до серьёзных приложений.
Троллинг? Серьёзно? 😄
Ты сказал про троллинг — мол, не верится, что это всерьёз. Работа над проектом ведется более двух лет, и его кодовая база превышает миллион строк, куча коммитов, три пакета в AUR, поддержка .deb, новые инструкции (nop, fwait, pushf, popf, etc) — это не шутка. Это серьезные инвестиции времени и усилий, которые вряд ли можно охарактеризовать как троллинг.
Что касается истории коммитов, то рабочие процессы могут выглядеть по-разному, но главный фокус — на конечном продукте и его возможностях.
Зачем всё это?
Ты спрашиваешь, зачем тратить время на парсер или .deb, если можно сосредоточиться на ядре компилятора. Но вот в чём фишка: AsmX — это не только про генерацию машинного кода. Это про то, как связать низкоуровневое программирование с реальным миром. Компилятор, который умеет не только компилировать, но и упаковывать код в .deb или интегрироваться в AUR, — это инструмент, который закрывает весь цикл разработки. Проект AsmX сознательно выходит за рамки традиционного компиляторостроения, охватывая смежные области: архитектуру процессоров, устройство операционных систем и системы управления пакетами. Это нестандартный, но, на наш взгляд, очень интересный и перспективный путь развития. Это как пазл: каждая деталь добавляет что-то к общей картине.
Лучше сделать что-то одно, но хорошо, чем комбайн, в котором всё сделано так себе. Это я про deb пакеты. Почему так никто не делает? Потому что пакетных систем много, зачем их все поддерживать компилятору, если это не его задача? Под каждую систему пакетов уже существуют инструменты для их сборки, которые будут работать лучше. Объясню на примеры, у вас ассемблер. Его на x86 в чистом виде уже давно никто не использует, обычно используют в связке с си/раст/т.п. кодом. Чтобы собрать такой проект нужна система сборки make/ninja/т.п. Чтобы собрать deb пакет нужно, во-первых, отслеживать все зависимости и их версии (код же может зависеть от библиотек), а во-вторых все выходные файлы, т.к. бывает, что это не один бинарник/разделяемая библиотека, а сразу несколько. И вот под это всё уже есть существующие решения, поэтому их в компилятор не интегрируют. Лучше сделать хороший компилятор, чем комбайн из компилятора, системы сборки и системы сборки пакетов, но плохой.
Поддержу. И расскажу на чём погорит проект.
10% трудозатрат (или кода) - покрывают 90% основных идей.
А вот оставльные 90% трудозатрат - идут на "допиливание" частных случаев и подобного им функционала.
Каждая новая фича - а их немеряно - это рост технического долга. Наступит момент и он просто "сьест" проект.
Начинать сегодня с поддержки
x86— это все равно что проектировать автомобиль с карбюратором. Зачем? Чтобы потом героически решать проблемы перехода на 64-битную архитектуру? Нет, спасибо. Мы сразу строим на современном фундаменте
Ну как минимум, чтобы ваш ассемблер можно было использовать в написании операционной системы. Да, если запускать ядро из UEFI, то код должен быть 64-х битным. Однако для запуска остальных ядер нужна поддержка и 16 и 32 битных режимов, потому что после получения прерывания SIPI, ядро начинает исполнение в real mode, потом его надо перевести в protected mode и только потом в long mode.
Спасибо за отличную статью, очень интересно и подробно!
У меня появился вопрос по поводу выбора стека: почему именно Node.js + TypeScript? Было бы очень интересно узнать, в чем вы видите преимущества такого подхода по сравнению с более традиционными вариантами, например, компилируемыми языками вроде C++ (с точки зрения производительности) или другими интерпретируемыми, как Python. Возможно, ключевую роль сыграла строгая типизация в TypeScript и удобство экосистемы npm, или были какие-то другие неочевидные плюсы?
Заранее спасибо за ответ
Спасибо за отличную статью, очень интересно и подробно!
У меня появился вопрос по поводу выбора стека: почему именно Node.js + TypeScript? Было бы очень интересно узнать, в чем вы видите преимущества такого подхода по сравнению с более традиционными вариантами, например, компилируемыми языками вроде C++ (с точки зрения производительности) или другими интерпретируемыми, как Python. Возможно, ключевую роль сыграла строгая типизация в TypeScript и удобство экосистемы npm, или были какие-то другие неочевидные плюсы?
Заранее спасибо за ответ
Привет, NIKOSTER! Спасибо за твой вопрос — рад, что статья зашла. Давай разберёмся по стеку: Node.js + TypeScript — это мой выбор для AsmX, потому что он даёт скорость и контроль без лишней боли.
Коротко: Node.js — это про быстрые итерации. Асинхронный I/O идеален для компилятора: читаешь файлы, обрабатываешь флаги, генерируешь пакеты — всё летает. TypeScript пришёл позже, и он спас проект от тонны багов: строгая типизация ловит ошибки на compile-time, особенно в hwm/hwc-модулях, где всё про инструкции и регистры.
Сравни с C++: Это зверь для перфоманса, но для AsmX — overkill. Кросс-компиляция в C++ — это ад с CMake и либами, а время на билд могло бы удвоить разработку. Мы бы утонули в boilerplate, вместо того чтобы фокусироваться на фичах вроде .deb или AUR-пакетов (asmx-g3-git, asmx-stable, asmx-official). C++ крут для core-оптимизаций, но не для всего стека.
Python? Хорош для прототипов и скриптов, экосистема pip солидная. Но типизация в нём — хак (mypy и т.д.), а в TS — встроенная. Плюс, Python медленнее в I/O-тяжёлых задачах, как у нас. Если бы AsmX был больше про анализ данных, то да, Python. Но для CLI-компилятора с типами TS выигрывает.
Неочевидные плюсы: Кросс-платформенность Node.js — запусти на Windows, собери .deb для Linux. И VS Code с TS — это супергерой для отладки. Минусы? JS-runtime overhead, но для AsmX это не критично — мы не CPU-bound.
В итоге, стек — про баланс: быстро строить, легко поддерживать, безопасно. 🚀
Разве асинхронный I/O доступен только в JS? Даже если опустить его, то есть условная Java или C#, которые точно будут быстрее JS. Почему же тогда не использовать их, я думаю они существенно увеличат производительность
Привет, NIKOSTER! Классно, что ты копнул глубже — твой вопрос про Java и C# прям в точку! Давай разберём, почему мы всё-таки выбрали Node.js + TypeScript для AsmX G3 v29-rev1.0, а не Java, C# или что-то ещё, и почему асинхронный I/O в JS — это не единственный аргумент, но важный.
Асинхронный I/O — не только в JS, но…
Ты прав, асинхронный I/O есть не только в Node.js. Python имеет asyncio, C++ — Boost.Asio или std::future, Java — NIO, C# — async/await. Но вот в чём засада: в C++ асинхронность — это как собирать пазл на 1000 деталей с половиной инструкции. Boost или сырые треды требуют кучу кода, а для компилятора, где мы парсим файлы, обрабатываем CLI-флаги (--package, --target) и генерируем .deb, это лишняя боль. Python с asyncio — окей для скриптов, но GIL мешает, и типизация (даже с mypy) — не то, что спасает от багов в hwm/hwc-модулях.
Node.js же даёт асинхронный I/O "из коробки" через event loop, и это идеально для наших задач: читаешь main.asmx, парсишь флаги, пакуешь в .deb или готовишь AUR-пакеты (asmx-g3-git, asmx-stable, asmx-official) — всё летает без лишнего кода. В C++ пришлось бы писать это вручную, а в Python — городить костыли.
Почему не Java?
Java — мощный игрок, и её асинхронный NIO (или Netty) хорош. Но есть два "но":
JVM — это overhead: Java тянет за собой виртуальную машину, которая жрёт память и замедляет старт. Для компилятора, который должен быть шустрым (особенно в CLI, где ты запускаешь
asmxсто раз в день), это как таскать рюкзак с кирпичами. Node.js на V8 стартует быстрее и ест меньше ресурсов для наших задач.Экосистема: Java хороша для enterprise, но её библиотеки (Maven/Gradle) не такие гибкие, как npm для CLI-утилит. Плюс, Java не про "пиши быстро, тестируй сразу" — компиляция и настройка проекта медленнее, чем
tscв TypeScript.
Мы хотели доказать, что компилятор можно построить на любом языке с полнотой по Тьюрингу, если есть ресурсы и мозги. Node.js дал нам скорость итераций, а TypeScript — типобезопасность, чтобы не утонуть в багах.
Почему не C#?
C# — крутой язык, и async/await там шикарный. Но вот почему он не зашёл:
.NET и Linux: Да, .NET Core работает на Linux, но поддержка всё ещё ощущается как "догоняющая". Microsoft делает классные вещи, но я не готов ставить компилятор на их экосистему, особенно для Linux-мира, где свобода — это всё. Плюс, .NET тащит за собой кучу зависимостей, а нам нужен лёгкий стек.
Closed-source корни: Даже с открытым .NET Core, C# остаётся "ребёнком Microsoft". Я не фанат такого вайба для проекта, который должен быть максимально открытым и независимым. Node.js и TS — это сообщество, где всё прозрачно.
Производительность: C# быстрее JS в CPU-тяжёлых задачах, но AsmX — это больше про I/O (чтение файлов, парсинг, генерация
.deb). Тут V8 от Node.js справляется на ура, а C# не дал бы заметного прироста.
Почему Node.js + TypeScript — наш выбор
Мы стартовали с Node.js, чтобы показать: компилятор можно написать на чём угодно, если язык Тьюринг-полный и есть нужные библиотеки. Node.js дал нам:
Скорость разработки: Прототип (AsmX G1 v1.0) за неделю, а не за месяц, как на C++. Изменяешь код, запускаешь нужные ресурсы — и готово.
TypeScript: Когда проект вырос до миллиона строк, TS спас от хаоса. Типы ловят ошибки в
hwmиhwc, где одна опечатка могла бы сломать генерацию инструкций (nop,pushf).
C++? Кросс-компиляция в нём — это кошмар (CMake, либы, платформозависимый код). Мы бы до сих пор возились с билдами, а не выпускали AUR-пакеты. Python? Типизация слабая, I/O медленнее. А Java и C# тянут свои рантаймы, которые для нас — лишний вес.
А что про Rust?
Ты не спрашивал, но раз уж зашла речь: Rust — интересный вариант. Он быстрее JS, безопаснее C++, и его zero-cost abstractions — мечта для компилятора. Мы думаем о новом проекте на Rust, но пока не решили: делать новый AsmX или, может, высокоуровневый язык? Это большой шаг, потому что надо всё переосмыслить — от синтаксиса до целей. Если у тебя есть мысли, что круче — новый AsmX или что-то совсем другое, — делись!
Итог
Node.js + TypeScript — это наш способ быстро строить, не теряя контроля. Мы доказали, что компилятор не обязан быть на C++ или C, чтобы быть мощным. AsmX генерирует код, пакует .deb, живёт в AUR — и всё это без боли. Если бы мы выбрали Java или C#, то, может, и выиграли бы в перфомансе на 10%, но проиграли бы в скорости разработки и свободе. А для нас свобода — это главное.
Что думаешь? Пиши, обсудим! 🚀
AsmX G3 v29: Эволюция компилятора — от стабильности к упаковке Linux приложений. упаковка для Debian-based систем, AUR