Лис
Если вы это всерьёз, то грустно как-то получается, товарищи. (Когда не видят/не понимают достаточно очевидных вещей. Имея при этом имперские амбиции.)
Нет, я не обижаюсь. И разъяснения мне дать нетрудно. Вопрос только, будет ли в этом толк...

Статья начинается с заголовка. Вы его точно читали?
Напомню: "Симкод — современный язык ассемблера".
И этим всё сказано. Тут вам и практическая значимость, и цели, и варианты/сценарии использования. Или вы не знаете, что такое «язык ассемблера» и для чего он нужен?

Язык ассемблера нужен для наглядного представления результатов компиляции языка программирования высокого уровня в машинный код, проще говоря: чтобы убедиться в том, что компилятор не выдал какую-то пургу. Анализировать современный машинный код x86-64 на порядок-два труднее, чем код на языке ассемблера.
(Также настоятельно рекомендую прочесть этот мой комментарий к статье и сравнение симкода с C--.)

Чем не устраивает/плох традиционный язык ассемблера для x86?
1. Раньше, когда различных инструкций в типичных программах использовалось мало, он был хорош, но сейчас всё изменилось. Современная система команд x86-64 с расширениями включает в себя свыше 1000 мнемоник и более 6000 различных инструкций (если считать по опкодам). Более того, если раньше отличия в мнемониках были хорошо заметны (например, ADD, SUB, CMP), то теперь многие мнемоники отличаются лишь в одной букве: VADDSD осуществляет скалярное сложение, а VADDPD — векторное; VCVTSI2SS воспринимает регистр-источник как целое число, а VCVTSD2SS — как вещественное двойной точности (обе эти инструкции преобразуют исходное значение в вещественное одинарной точности).
2. Слишком сильно привязан к английскому языку. Если избавиться от мнемоник, то перевести с английского достаточно только имена регистров.

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

Симкод — это не термин/понятие, это название языка ассемблера. Также как C++ — это не термин, и Python — это не термин.
Если вас интересует более детальное [чем в данной статье] обоснование выбора такого названия, то симкод в чём-то созвучен понятию автокод и по задумке будет:

• симкод — символьный машинный код (язык ассемблера, т.е. язык самого низкого уровня) и

• сипкод — символьный промежуточный код (аналог языка LLVM IR, т.е. язык промежуточного представления, который, как можно догадаться, основан на символьной записи, в отличие от языка LLVM, который основан на мнемониках).

(И для обоих «си-кодов» планируется поддержка русского языка.)

Как я уже писал в статье: «у меня уже есть достаточно хороший вариант перевода [всего симкода, в т.ч. всех регистров x86-64, разумеется]. Но пока что разглашать я его не буду.»
Не буду до тех пор, пока не выскажутся все заинтересованные в таком переводе.
Вас, кстати, я тоже приглашаю поучаствовать (в самом конце статьи есть ссылки на текстовый файл варианта перевода на 5-ти различных платформах). Но пока что, желающих поучаствовать, увы, не нашлось.

Поддерживаю (про «вражескость» Си), но прямо написать об этом в статье на Хабре я не мог, вы же понимаете?
Заодно отвечу здесь на вопрос Юрия:

Нет. Симкод не основан на Си. Он основан на 11l. Именно из него и был позаимствован оператор (+).
И если учить язык программирования с нуля (что 11l, что симкод, при этом совсем не зная до этого язык Си и другие Си-подобные языки), то очень сложно дать разумное обоснование выбора символа карет (^) для операции «исключающего ИЛИ». А обоснование выбора (+) достаточно логично, и оно приводится в статье про симкод и в документации к 11l.

Давайте всё же мухи отдельно, котлеты отдельно.

1. Если вы не согласны с тезисом про завершённость и проработанность, то покажите конкретный пример более завершённого и проработанного проекта символьного языка ассемблера x86. Я уже упоминал в статье terse и HLA, которые не поддерживают даже x86-64, не говоря про AVX.

2. Реализация симкода написана не на «питоне», а на «компилируемом Python» — подмножестве Python, которое компилируется в нативный код посредством транспайлера Python → 11l → C++. Писать реализацию симкода на самом симкоде (и не важно на английской его версии или на русской) — это глупость и безумие, т.к. симкод вообще не предназначен для написания на нём кода, это во-первых; во-вторых, трудоёмкость написания на любом языке ассемблера выше трудоёмкости писания на Python на один-два порядка, таким образом если текущая реализация (которая переводит только в одну сторону — в симкод) заняла у меня 3 месяца работы, на языке ассемблера это заняло бы минимум 30 месяцев работы (но как человек, который имеет практический опыт написания кода на языке ассемблера, я бы не взялся за такую работу даже за очень хорошие деньги); и в-третьих, использование «компилируемого Python» даёт две "уберфичи": 1) утилита доступна онлайн в браузере благодаря Brython вообще без какой-либо адаптации исходного кода и 2) исходный код утилиты русифицируется буквально на раз-два — сначала посредством транспайлера Python → 11l получается полностью человекочитаемый код на 11l (транспайлер специально разрабатывался так, чтобы сгенерированный им код был почти такой, как если бы он изначально писался не на Python, а на 11l; поэтому я хоть и выбираю для большинства своих проектов язык Python, фактически они получаются уже написанными на 11l; просто Python удобнее отлаживать и запускать, пока не готов полноценный компилятор 11lc). Это раз. И два — путём запуска простенького скрипта (наподобие этого) из английского кода 11l получится код на русском 11l.
А бутстрап тоже будет, но на уровне 11lc (который будет написан на 11l). Нет смысла бутстрапать симкод.

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

Предложение «Если избавиться от мнемоник, то перевести с английского достаточно только имена регистров.» не нужно понимать буквально как стремление к полному отказу от мнемоник. Это я говорил образно, гиперболизированно.

Если же хотите увидеть, что конкретно я предлагаю, достаточно просто открыть веб-версию консольной утилиты symasm и вбить команды
VADDSD xmm0, xmm1, xmm2
VADDPD xmm0, xmm1, xmm2
VCVTSD2SS xmm0, xmm0, xmm1

Решил выложить сюда подробное, по пунктам, моё разъяснение того, почему нет смысла делать реализацию сим-ассемблера (ассемблера симкода) на самом симкоде:
1. Невероятно высокая сложность программирования/реализации на языке ассемблера крупных проектов (а ассемблер для любой современной архитектуры неизбежно будет являться крупным проектом банально по причине большого количества существующих инструкций в современных процессорах).
2. Традиционные языки ассемблера существенно проще парсить, чем симкод. Таким образом, реализовать сим-ассемблер ещё сложнее [чем традиционный ассемблер].
3. Разобраться в написанном ассемблерном коде может только тот, кто его написал. Если посмотреть на страницы проектов fasm, fasm2 и fasmg, то видно, что Томаш Грыштар является единственным контрибьютором у этих проектов. И это при том, что fasm является всемирно известным проектом и существует много-много лет. После ухода из жизни Томаша, очевидно, никто не возьмётся поддерживать разработку fasm (т.к. существует много других ассемблеров, написанных на Си и более высокоуровневых языках). Томаш совершил подвиг. Но повторять этот подвиг уже нет никакого смысла.
4. Для того, чтобы иметь хоть какую-то возможность использовать язык ассемблера для разработки крупного проекта, приходится использовать макросы. Тот же fasm имеет очень мощный макропроцессор. Я же не вижу смысла делать такую штуку для симкода вообще — макросы используются для написания кода (а симкод нужен для чтения) и это ещё один "недоязык", плодить которые я не хочу.
5. Код, написанный на языке ассемблера, жёстко привязан к одной архитектуре процессора. Даже если x86 останется с нами навсегда, тот факт, что fasm работает только на одной архитектуре x86 уже сейчас неудобен — на ARM или RISC-V процессоре напрямую запустить fasm не получится. (Да, fasmg может производить машинный код для различных процессорных архитектур, но сам то он работает только на x86.)

В принципе, если поставить задачу реализации только минимального набора ассемблерных инструкций, необходимых для раскрутки ассемблера, то эта задача существенно проще реализации полноценного ассемблера типа fasm, поддерживающего все инструкции архитектуры x86. Вот только какое практическое применение у такого "урезанного" ассемблера? Ведь кроме компиляции самого себя он ни на что не пригоден. Чтобы его можно было практически использовать, необходимо добавить поддержку большого количества инструкций, используемых компиляторами языков высокого уровня. А для реализации такого проекта использовать язык ассемблера абсолютно нецелесообразно (по причинами, которые я только что перечислил [кроме разве что 2-й, которая специфична для сим-ассемблера]). Значит, для реализации полноценного ассемблера придётся использовать какой-то более высокоуровневый язык программирования, и необходимо будет переписать реализацию ассемблера уже на этом языке. Но тогда возникает вопрос, а что делать с исходным кодом уже написанного "урезанного" ассемблера? Выкинуть? Ведь ничего другого по сути и не остаётся. Тогда зачем его вообще реализовывать [этот "урезанный" ассемблер]?

Почему? Mожно перейти на сим-ассемблер в дальнейшем, после реализации простого синтаксиса.

Эту сложность можно преодолеть. Классифицируйте команды.

Возможно, попробуйте упростить его сначала. Задача найти множество L0 для раскрутки.

Думаю нет, могут разобраться и другие. Вначале так и бывает в начале один человек везет, потом к нему подключаются если у него есть такая заинтересованность и есть ли у других такая заинтересованность.

Скорее больше подходит высокоуровневый язык для крупных проектов, а не непосредственно ассемблер.

Это верно в части регистров, организации памяти.

fasm наверное тоже не сразу оброс функционалом.

Да, урезанный ассемблер при раскрутке написанный на другом языке не понадобится.

Для раскрутки. Он должен быть максимально простым.

Отредактировано ИванАс (2024-10-01 15:45:08)

слишком кратко, распишите.

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

Язык С\С++ относится к языкам высокого уровня по вашему мнению?

все на уровне общих слов. Какая структура?

Отредактировано ИванАс (2024-10-01 17:28:18)

Плохо приспособлен, не значит что не невозможно. Вы выдаете не правильные ответы. ЧТД.