Комментарии 8
Несколько слов об обратной связи. Я ценю любую конструктивную критику, потому что она помогает мне делать проект лучше. Если вы решите поставить этой статье минус, я буду благодарен, если вы оставите комментарий и объясните, что именно можно улучшить. Конечно, это не требование — лишь ваш выбор.
Если же вам просто не по душе мой проект или стиль, и нет желания вступать в диалог — пожалуйста, просто пройдите мимо. Я, как и любой автор, создаю AsmX для тех, кому это действительно интересно, и с радостью продолжу делиться своими наработками с этим сообществом.
И да, я хочу добавить кое-что от себя.
Я верю, что у каждого автора есть право делиться своими проектами и идеями, даже если они идут вразрез с мейнстримом. К сожалению, мой прошлый опыт показал, что иногда критика переходит в целенаправленную травлю, цель которой — не улучшить продукт, а лишить автора права на творчество.
Поэтому я хочу прояснить: это не призыв к спорам ради споров или троллингу. Если ваша цель — не диалог, а просто желание выплеснуть негатив, то я искренне прошу вас не тратить на это ни своё, ни моё время.
Этот проект — мой путь, и я намерен пройти его до конца, как бы ни было сложно.
Спасибо всем, кто поддерживает, задаёт вопросы и помогает двигаться вперёд. Именно для вас я и делаю AsmX.
Несколько слов об обратной связи. Я ценю любую конструктивную критику, потому что она помогает мне делать проект лучше. Если вы решите поставить этой статье минус, я буду благодарен, если вы оставите комментарий и объясните, что именно можно улучшить. Конечно, это не требование — лишь ваш выбор.
Если же вам просто не по душе мой проект или стиль, и нет желания вступать в диалог — пожалуйста, просто пройдите мимо. Я, как и любой автор, создаю AsmX для тех, кому это действительно интересно, и с радостью продолжу делиться своими наработками с этим сообществом.
И да, я хочу добавить кое-что от себя.
Я верю, что у каждого автора есть право делиться своими проектами и идеями, даже если они идут вразрез с мейнстримом. К сожалению, мой прошлый опыт показал, что иногда критика переходит в целенаправленную травлю, цель которой — не улучшить продукт, а лишить автора права на творчество.
Поэтому я хочу прояснить: это не призыв к спорам ради споров или троллингу. Если ваша цель — не диалог, а просто желание выплеснуть негатив, то я искренне прошу вас не тратить на это ни своё, ни моё время.
Этот проект — мой путь, и я намерен пройти его до конца, как бы ни было сложно.
Спасибо всем, кто поддерживает, задаёт вопросы и помогает двигаться вперёд. Именно для вас я и делаю AsmX.
Друзья, я один из немногих, кто поддержал ваше начинание: ставил плюсы под статью и в карму. К сожалению, но ожидаемо эта статья вышла в Recovery Mode.
Много пафоса в тексте?! –пусть. В наше время хвост нужно держать пистолетом. Я даже принял в сердце Маска: кто-то ведь постит котиков, и все умиляются «милота», так почему бы кому-то не постить Илона?
По существу:
Не ясен кому этот проект нужен (то есть нет заказчика). Если бы хотя бы сам автор сказал: «меня не устраивают существующие компиляторы тем-то и тем-то, а этот решает мне здесь конкретную проблему», то уже было б ясно, что у проекта есть хотя бы 1 пользователь.
Идея описать команды наборами их свойств – хороша. Зачем? Очевидно, чтобы а) унифицировать описание команд различных процессоров б) унифицировать алгоритм кодогенерации под разные процессоры в) оптимизировать алгоритмы при трансляции их с ЯП-ов в ассемблер. Но при таком подходе сначала делают функциональную модель с элементами математики, и на ней проверяют и корректируют гипотезы. Этого шага нет.
Код проекта и по структуре и по написанию ужасен: вышеуказанные таблицы описания процессоров должны быть отделены от алгоритмов, а в проекте идёт их помесь. Если бы описание команд под каждый процессор хранилось в отдельном Json-е, а компилятор вычитывал их и работал с ними – было бы лучше.
Далее, эта информация из таблиц важна именно оптимизатору алгоритмов, т.к. «линейно» переводить алгоритмы с ЯП-ов по жёстко данным шаблонам – это все умеют. А про оптимизацию алгоритмов в вашем проекте – ни слова. Кто, как, будет этим заниматься? Предположу, что LLVM, который славен именно оптимизирующей компиляцией, имеет подобные таблицы (в том либо ином виде).
Не следовало сразу браться «объять весь мир». Взяли бы достаточное минимальное подмножество регистров и команд процессора x86 (и Z80 почему нет?!), с важными случаями, и над ними сделали небольшой прототип, где протестировали гипотезы, и продемонстрировали его миру.

Дружище, иди в продажники, ты же талант!
А по делу: я глянул по диагонали код, я же правильно понимаю, что команды JMP не поддерживаются никакие, ни условные, ни безусловные, что делает эту штуку пока бесполезной для программирования?
movfuscator как то программируется

Видение требует ясной коммуникации. Спасибо.
Вы правы, условные и безусловные переходы еще не влиты в основную ветку. Но делать из этого вывод, что система "бесполезна" — это рассуждать по аналогии, и это фундаментальная ошибка.
Мы строим не очередной мусор. Мы строим итерации с нуля. Первый принцип: сначала нужно создать надежные модули. Наш hwm
— это модуль для кодирования инструкций. Наш генератор ELF — это сборочная линия. Они должны работать безупречно, прежде чем мы начнем производить новые инструкции.
Переходы (JMP
) — это система управления потоком. Ее реализация становится тривиальной, когда у тебя есть надежный пятитактный двигатель hwm
и hwc
(сборщик elf). Судить о первом калибровочном запуске двигателя по его неспособности доехать до Марса — значит... не понимать процесса.
Проект выглядит очень амбициозным. Немного сомнительно слушать этот посыл вначале, что другие компиляторы слишком сложные, а вот мы напишем что-то более простое и лучше. Скорее всего когда проект достигнет стадии промышленного использования через несколько лет он будет таким же сложным, т.к. предметная область сложна. Эволюция какая-то возможна, как например было у gcc и clang, главное чтобы доступные ресурсы соответствовали амбициям.

Отличный комментарий. Вы абсолютно правы: сложность — это главный враг.
Строить многоразовую ракету тоже казалось "слишком амбициозным", пока все пытались улучшить одноразовые. Проблема была не в физике, а в подходе. Мы не "улучшаем" компилятор; мы переизобретаем его архитектуру, чтобы сложность была управляемой, а не хаотичной.
Именно поэтому нам нужны такие скептики, как вы. Присоединяйтесь к проекту. Помогите нам доказать, что можно сделать иначе. Или наблюдайте со стороны. Мы в любом случае это сделаем.
И друзья, давайте не будем стрелять по карме пианисту: он играет - как умеет! Ведь есть замечательная кнопка "скрыть публикации атора", пользуясь ей вы делаете мир лучше!
AsmX G3: Архитектура кодировщика ZGEN. Как hwm генерирует машинный код amd64