Но интерпретатор - всё же среда исполнения, а не преобразователь smile

С первым согласен. Со вторым — нет.

Расскажите.

См. боян в предыдущем посте

В самом низу - трансляция - буквальный перевод мнемоник (не команд!) в машинный код. Текстовый исходник -> трансляция -> бинарный файл (обычно obj).
Выше - компиляция - перевод "литературный": команды имеют немашинную (предполагается - человеческую) семантику, результирующий код зависит от контекста (одна и та же команда, использованная, скажем, в начале файла и в подпрограмме даст разный результат в машинном коде (область видимости, стэк и т.д.), соответственно и обработка производится в несколько проходов - анализируется контекст, блоки команд (процедуры, подпрограммы) команды и т.д. Трансляция на последнем этапе присутствует, но не из ассемблера, а из некоего промежуточного кода, зависящего от конкретного компилятора. На выходе (обычно) - готовый экзешник.
На самом верху (по оторванности от железа) - интерпретация - текстовый исходник обрабатывается интерпретатором налету, без преобразования в бинарный файл. В те времена - шелл да комманд.ком...

Меня несколько иначе учили. Три типа обработчиков исходного кода,

Расскажите.

Транслятором является как интерпретатор, так и компилятор. Просто действуют они по-разному.

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

Что? Программа masm.exe называется Macro Assembler, tasm.exe - Turbo Assembler... Это я и имел в виду. А священные войны за кошерную терминологию - это не моё. Здесь я на редкость демократичен.

serzh82saratov, боян, но, надеюсь, хорошо забытый:
команда начальника: "Чёзанах?"
интерпретация: сотрудник думает: "в следующий раз надо не умничать, а делать что говорят...";
компиляция: бухгалтерия срезает половину премии сотрудника, сотрудник, получив в кассе машинный код, делает что говорят;
трансляция: сотрудник расстёгивает ширинку и правда - чё?

Ассемблер переводит исходник буквально, даже не так, как переводят с русского на английский - там обработка текста есть, а так, как текстовый файл переводится из кодировки UTF-16 LE в UTF-16 BE и обратно. Однозначно и без изменения имеющейся информации. Переводит, разумеется, программа-транслятор.

и

Каким именно образом переводится? Как, когда и что этот перевод осуществляет?

alexii, во-первых, я обозвал ассемблер транслятором в ответ на заявление, что он - интерпретатор, в данном контексте не вижу ошибки;

Транслятором является как интерпретатор, так и компилятор. Просто действуют они по-разному.

Совсем не понял.

Цель — договориться о корректной терминологии.

Ассемблер - ни разу не интерпретатор, он - транслятор. А означает это, что исходник на ассемблере и машинный код могут быть сколько угодно раз транслированы туда-обратно. И если человеческая логика позволяет что-то оптимизировать в машинных кодах, то и на ассемблере эта оптимизация доступна, хотя бы дизассемблированием. Возможны проблемы с внешними макросами / библиотеками процедур, но это не проблема ассемблера. Видел парочку "продвинутых" ассемблеров, типа объектноориентированные и т.д., но это уже либо компилируемый язык, либо ассемблер со встроенными теми самыми библиотеками. Поэтому, земляк, хоть голословно, хоть нет - не убедил.

Я ничего не утверждаю, и тем более ни кого не убеждаю, хотя бы в силу своего дилетантизма. Вообще завёл речь про это, чтобы из возможного дальнейшего обсуждения подчерпнуть знаний для себя. А так как на лицо разногласия между гуру, значит вопрос неоднозначен.
Код на ассемблере это текстовый файл. Машинный код - единицы и нули, единственное что может понять процессор.
Перед тем как запустить в работу машинный код для непосредственной обработки процессором, требуются ресурсы для интерпретации текста ассемблера в машинный код.
Машинный код это бинарный файл, он принимается в обработку процессором без предварительного выделения ресурсов на его интерпретацию.

Человеческая логика может только заранее предусмотреть некоторые варианты того что может наваять программер, и внести это в алгоритм интерпретации текста в машинный код.
Конечно можно легко полученный машинный код преобразовать обратно в код ассемблера, через "обратный алгоритм интерпретации" того же ассемблера, но речь ведь совсем не об этом. А про то что машинный код интерпретированный ассемблером можно в большинстве случаев далее оптимизировать исходя из каждого конкретного случая.

Это мои предположения. Если тут присутствуют глубокие заблуждения, прошу не пинать ногами, а просто объяснить что не правильно.

А вообще - не понял, о чём Вы и greg zakharov со мной-то спорите? Вроде, я в своём ответе земляку был на Вашей стороне, или главное - спорить?

это скорее касательно стиля написания программ (точнее оптимизации кода), нежели "излишеств" ассемблера, - г-н alexii прав.

Там суть в том, что человек раскладывал простейшие операции\алгоритмы на ассемблере в виде машинного кода. И показывал как их можно логически упростить и сократить на том же машинном коде.

Не знаю, что там происходило, но вообще-то 1 инструкция ассемблера = 1 инструкция процессора. Просто вместо машинного кода, т.е. числа, используется какое-то условное имя (мнемоника), чтобы человеку проще было инструкции запомнить. Да, какой-то конкретный ассемблер может предлагать какие-то свои макросы для ускорения написания кода, например, оформление функций. Вход в процедуру, выход из неё и т.п. В каких-то случаях стандартная обвязка может быть неоптимальной, но всегда можно обойтись без неё или свою написать.

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

Каких именно?