Привет, 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. Тоже вариант. Но современные студенты - это уже даже не зумеры. Это альфы. Им надо красивые картиночки, они без картиночек не могут
