[quote="Хищник] ... Недостаток - требуется изучение системы команд во всех вариантах, чтобы не закрыть себе дорогу к ассемблированию какой-либо комбинации.[/quote]
Да, в этом варианте сами операнды должны принимать решение
применимы ли они к требуемой команде:)

[quote="Гость"]Пример:
MOV AX, BX; \ адрес исполнения MOV просто запоминается где-то
\ по ; или следующей мнемонике производится исполнение
\ запомненного MOV для формировния кода операции
\ между MOV и ; используется Форт синтаксис [/quote]

Кажется, было у Черезова. Есть словарь мнемоник и словари операндов. Как только набраны слова из всех трех словарей (двухЮ одного) - происходит генерация команды. Недостаток - требуется изучение системы команд во всех вариантах, чтобы не закрыть себе дорогу к ассемблированию какой-либо комбинации.

При проектировании ассемблера можно, как вариант,
сделать небольшой "финт ушами"

Пример:
MOV AX, BX; \ адрес исполнения MOV просто запоминается где-то
\ по ; или следующей мнемонике производится исполнение
\ запомненного MOV для формировния кода операции
\ между MOV и ; используется Форт синтаксис

P.S. При этом МОV не проводит анализа входного потока:)

[quote="in4"]Ага! И я о том же! Smile
Причем, похоже, мы подходим к ассемблеру с разных сторон - ты хочешь пополнее покрывать все имеющиеся команды,
а я - иметь этих команд поменьше (меньше примитивов)! Smile
Но при этом я и не против обоснованного расширения набора примитивов! Wink [/quote]

Ну вобщем да. Причем противоречия никакого нет - я просто предлагаю вариант работы с чисто нуль-операндным подходом. Минимальный набор требует меньших усилий, вопрос был только в том, насколько годится такой подход для более менее серьезной системы команд. Практика показывает, что годится. Но разумеется, никто не загоняет хворостиной делать обязательно все команды, типы и подтипы.

[quote="in4"]Ты, кстати, тоже предлагаешь ассемблер для ВМ! Пример - STACKххх Wink
И, IMHO, 0 операндный м.б. иногда не очень удобен по синтаксису...
[/quote]
Ну да, там идет плавное перетекание в примитивы Форта. А уж удобство - второй вопрос. "Кормить в пути никто не обещал" :)
[quote="in4"]По сути ты предлагаешь практически новый язык (если судить по именам слов).
Рассмотри использование диалекта Форта в качестве своего ассемблера(или постепенный переход на него)! И учитывай при этом возможности расширения даже набора примитивов... [/quote]
А чего рассматривать-то? :) Уже давно для софт-процев используется грамматика подобного вида. Прямая, как палка - каждая команда имеет код. Список команд - список кодов.
[quote="in4"]Вот единственно, что неудобно в этом случае - программистам (привыкшим работать) на асме прийдется учить Форт! Wink
Но доп. обучение все равно нужно - у тебя синтаксис не асмовый, хотя похоже...
Так может... Wink[/quote]
Ну уж.... кому надо, тот научится. Распространять и предлагать у меня намерения нет. Мое дело - показать, что так делать можно, и что именно нужно сделать, чтобы получилось. Это же моя внутренняя кухня (причем в прямом смысле - я тут на кухне вечерами с ноутом отлаживаю прибор с форт-процессором :) Если наработки пригодятся кому-то еще - я опубликовал, на то и конференция. Но я же не должен "плакать, колоться, но продолжать жрать кактус", встраивая в проприетарную разработку какие-то поддержки стандартов, или добиваясь соответствия умозрительно сформированным требованиям?

[quote="Хищник"]И в реальных проектах удобно работать как раз с чуть расширенным набором команд, поскольку дополнительные команды могут хорошо ложиться на стиль мышления применительно к конкретной задаче. [/quote]
Ага! И я о том же! :)
Причем, похоже, мы подходим к ассемблеру с разных сторон - ты хочешь пополнее покрывать все имеющиеся команды,
а я - иметь этих команд поменьше (меньше примитивов)! :)
Но при этом я и не против обоснованного расширения набора примитивов! ;)

Вот я еще раз перечитал тред - основные идеи у нас оочень похожи. Есть только различие в акцентах и применяемых терминах... ;)
Ты, кстати, тоже предлагаешь ассемблер для ВМ! Пример - STACKххх ;)
И, IMHO, 0 операндный м.б. [b]иногда[/b] не очень удобен по синтаксису...

Еще раз подчеркну, что иметь расширяемый язык(форт например) в качестве ассемблера - это удобно. Особенно для софтпроцов!
А спцфисские команды ему можно дописывать хоть при создании, хоть потом.
По сути ты предлагаешь практически новый язык (если судить по именам слов).
Рассмотри использование диалекта Форта в качестве своего ассемблера(или постепенный переход на него)! И учитывай при этом возможности расширения даже набора примитивов...
Вот единственно, что неудобно в этом случае - программистам (привыкшим работать) на асме [b]прийдется[/b] учить Форт! ;)
Но доп. обучение все равно нужно - у тебя синтаксис не асмовый, хотя похоже...
Так может... ;)

[quote="Гость"]Полность согласен,
но выбор как в известном мультике
- "Полдня потерять, а после за пять минут долететь"[/quote]

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

[quote="Хищник"]Но если мы процессоры делаем быстро, то инструментарий написать просто не успеем! Тут уж не до жиру, была бы возможность поковырять свежесозданное ядро.[/quote]

Полность согласен,
но выбор как в известном мультике
- "Полдня потерять, а после за пять минут долететь"

[quote="Гость"]Интересно рассмотреть такой подход в рамках создания универсального ассемблера.[/quote]

Здесь, опять же, возникает следующее соображение. Машинная лингвистика - это все хорошо. Большим, мощным и красивым ассемблером мы закладываем фундамент для эффективного выполнения последующих разработок, в том числе и людьми, которые тонкостями постреония трансляторов не владеют. Им надо выдавать диагностику на уровне "вы пытаетесь сделать mov [mem], [mem], а так нельзя". Рассмотренный же ассемблер выдаст только одну ошибку "не знаю такого слова" :) Но если мы процессоры делаем быстро, то инструментарий написать просто не успеем! Тут уж не до жиру, была бы возможность поковырять свежесозданное ядро.

Интересно рассмотреть такой подход в рамках создания универсального ассемблера.

А.А. ИВАНОВ. Обобщенное описание семантики в двоично-транслирующей системе с платформы Intel на платформу Эльбрус. - "Высокопроизводительные вычислительные системы и микропроцессоры" - сборник научных трудов ИМВС РАН, 2003 г., стр. 44-54. (http://www.imvs.ru/imvs/collect/2003/44_54.pdf).

P.S. ссылка взята с http://www.mcst.ru/pub.shtml

[quote="in4"]Интересно упростить набор, но чтобы он оставался функционально полным. 4х битные команды - это намного проще! И транслятор в такой набор команд не так сложно сделать... Wink
С меньшим набором удобнее работать... [/quote]

Ну вот, приехали! А ради чего я все это писал? Речь как раз о том, что транслятор-ассемблер можно сделать на сколько угодно сложную систему команд, если четко придерживаться префиксной формы записи. И в реальных проектах удобно работать как раз с чуть расширенным набором команд, поскольку дополнительные команды могут хорошо ложиться на стиль мышления применительно к конкретной задаче. Вот сейчас поползу добавлять SIMD-расширение к проекту :)

[quote="Хищник"]В чем проблема с не-софт процессорами?[/quote]
У обычных процов сложная система команд, а у x86 даже несколько вариантов одной и той же команды.
Интересно упростить набор, но чтобы он оставался функционально полным. 4х битные команды - это намного проще! И транслятор в такой набор команд не так сложно сделать... ;)
С меньшим набором удобнее работать...

Для софтпроцов ты можешь подбирать(выбирать из нескольких прохожих) набор команд, ориентируясь на задачу и он будет оптимальным (для нее!)
Например, все 4 команды какого-нибудь устройства можно закодировать всего 2мя битами. И в один байт насовать их 4 штуки :)
Для обычных процов такой вариант не пройдет - надо или реализовывать ВМ или компилятор в нативный(большого размера) код.

И вот для нескольких похожих можно играться с набором реализованных команд. Код программ не меняется, если в системе команд присутствует только часть команд, а остальные сделаны макросами. Даже не меняется, если сделаны разные наборы команды/макросы. Именно в этом случае и удобны такие виртуальные системы команд!

[quote="in4"]Вот я и присматриваюсь к этому как раз для быстрой портируемости.
А в свете софтпроцессоров это будет самым подходящим решением! Wink[/quote]

Я как раз склоняюсь к безоперандному подходу. В чем проблема с не-софт процессорами? Надо выражать то, что хочется, путем комбинирования того, что есть. А есть некие кирпичики. В софт-процессоре кирпичики в основном совпадают с нашими представлениями об их функциональности. Так что можно делать сразу +, а не "забрать, забрать, сложить, вернуть".

[quote="Хищник"]Здесь -> - забрать со стека в первый регистр, --> - во второй, (+) - сложить "арифметические" регистры, <- - отправить регистр на стек. Из таких вещей можно было набрать команды Форта для разных архитектур, [/quote]
Вот я и присматриваюсь к этому как раз для быстрой портируемости.
А в свете софтпроцессоров это будет самым подходящим решением! ;)

У меня была поделка на уровне

: + -> --> (+) <- ;

Здесь -> - забрать со стека в первый регистр, --> - во второй, (+) - сложить "арифметические" регистры, <- - отправить регистр на стек. Из таких вещей можно было набрать команды Форта для разных архитектур, но по размышлению стало ясно, что возиться с лишней сущностью себе дороже. Можно и справочник по командам посмотреть, особенно с учетом того, что хорошие вещи с бухты-барахты все равно не получаются. :)

[quote="Хищник"]Не, это уже другая тема. [/quote]Да. Другое возможное решение, другая методика. Отделение от реального ассеблера вообще! ;)[quote="Хищник"]Нельзя однозначно решить, что вот, дескать, мы обойдемся виртуальной машиной. Кто-то обойдется, кто-то нет. И вот для тех, кто нет, написана статья.[/quote]И для них же можно к ВМ [b]дописывать[/b] комады! ;)
Самое серьезное неудобство ВМ-АСМа - трудно быстро добавить непредусмотренную ранее команду - надо в справочник проца смотреть! Но обычно при реализации твоего варианта расписывают [b]все[/b] возможные команды...
Так что мое предложение можно рассматривать как врЕменное решение, когда (или пока?) нет твоего... ;)
А твое удобнее и полнее... Если бы у меня оно тогда было... ;)