Привет, WASM. Работаю над средой разработки, где высокоуровневый код, ассемблер и машинный код — это три синхронизированные колонки (похоже на Hiew, но с двусторонним редактированием). Изменение в любой колонке автоматически пересчитывает остальные. Идея не в том, чтобы заменить существующие инструменты, а в том, чтобы дать единую поверхность для разных задач: Для опытных разработчиков и при разборе чужого кода: можно выделить интересный низкоуровневый фрагмент в первых двух колонках и в редакторе третьего столбца оформить его как свою пользовательскую команду. Дальше она используется как обычная абстракция, но без потери прозрачности: всегда можно развернуть и посмотреть, что там внутри. Это способ фиксировать и переиспользовать низкоуровневые трюки. Для проектирования железа и разговора с производителями: через редактор первой колонки можно проектировать собственную логику команд и формировать спецификацию: «хочу вот такие команды, вот сколько тактов они занимают, вот сколько логических элементов нужно». Четвёртая (сейчас скрытая) колонка даёт прогноз стоимости: такты, логические элементы, энергозатраты. Для обучения и перехода от высокого уровня к железу: студент видит не абстрактную теорию, а прямой путь: высокоуровневая абстракция → ассемблер → машинный код → стоимость в тактах и элементах. Это помогает сформировать интуицию о цене каждой строчки кода. Хочу услышать мнение сообщества не про сам язык, а про такой подход к инструменту: Насколько востребована возможность создавать свои команды поверх существующего ISA именно в реальной разработке (не в экспериментах)? В каких задачах это реально экономит время? Есть ли подводные камни в самой идее двустороннего редактирования (изменение машинного кода → пересчет ассемблера и высокоуровневой абстракции)? Где такая модель ломается на практике? Насколько реалистично использовать такую среду как спецификацию для проектирования железа? Какие метрики и данные в ней были бы действительно полезны для разговора с производителем чипов? Как вы видите место такого инструмента в современном рабочем процессе? Это дополнение к существующим IDE/ассемблерным средам, или отдельная ниша? Не ищу похвалы. Мне нужны жёсткие контраргументы: где эта идея упирается в реальные ограничения компиляторов, ISA или производственных процессов. Спасибо за любые мысли.
Если я не ошибаюсь, компиляция - это процесс с потерями. Информация об именах переменных, типах данных, структурах управления (циклы, условия) безвозвратно теряется, если только компилятор специально не сохранил её в отладочных символах.
GUI Как человек, работающий с графикой, скажу: колонки - это не всегда удобно. Количество строк на ЯВУ всегда будет меньше количества инструкций, поэтому первая колонка будет полупустая. Как изменять размер окна/колонок? Тот же вопрос для случая, когда у пользователя два монитора. А если у кого-то один, но маленький (например, ноутбук у студента). Содержание 1. ЯВУшники пишут код лесенкой по поводу и без повода, поэтому в первой колонке будет видно только начало строки, тогда строку придётся переносить, и их драгоценная лесенка потеряет смысл. 2. Какой смысл в колонке машинного языка без состояния регистров и дампа памяти? Имхо По описанию Ваша концепция похожа на "визуальное программирование". Я уже живо представил себе Dynamo из Revit, Param-O из ArchiCAD или Grasshopper для Rhinoceros 3D. Ну или Scratch для студентов MIT. Имхо, такое представление было бы вполне современным: кликабельный нод с кодом ЯВУ, а по клику появляется тег с пояснением
Как человек иногда пишущий на dephi 7, скажу. Сделать в виде 3 отдельных вкладок. Все это можно добавить в последней вкладке. Они не обязательно должны быть одинаковыми по инструментарию. Имхо, добавить точки останова в эту вашу ide, тогда будет благодать.
Кстати, предлагаемый подход исключает оптимизацию --- Сообщение объединено, 9 окт 2026 в 16:20 --- Tabbed-interface. Тоже вариант. Но современные студенты - это уже даже не зумеры. Это альфы. Им надо красивые картиночки, они без картиночек не могут
Вообще идея хорошая. Интерпретатор языка BASIC - это банальность. Интерпретатор Явы, Питона - тоже не удивишь. А вот интерпретатор C++26 - это что-то свежее. Стоит попробовать. Ещё между ЯВУ и ассемблером надо предусмотреть таб с байт-кодом. Ну, как бы. Для полноты
Всегда было интересно можно ли написать норм компиль C/C++ на питоне. Там есть хорошие средства парсинга. Без длинных портянок кода как в gcc.
Лучше средства для парсинга С/С++, чем libclang, ты не сделаешь. И в принципе мечтать об интерпретаторе С++26 - это утопия, хотя бы с точки зрения того, что придется в какую-то сторону завернуть все возможные undefined/unspecified behaviour, в какую-то сторону определить все зависимые от платформы вещи int/long/long int и многие еще непростые вещи.
Тогда для ассемблера (fasm/masm синтаксис). Имхо, там гораздо проще чем парсинг С/С++. Open Source компилятор в 1000-1500 строк. Python выигрывает не в скорости, а в том, что задача ложится на его сильные стороны.
Application, Ты хочешь не интерпретировать язык, а эмулировать компилятор. A=B, C=B, out=C. В двух случаях результат разный, до компиляции есть переменные и taint, после компиляции этих сущностей нет. Раньше нужно было понять язык, это недалеко от совершенства делают бям и могут символическое исполнение и восстановить логику. Теперь же нужно наоборот, какой то невнятный изврат с компиляцией, wtf?. Это какая то плохая школа.
