Здравствуйте, Shmj, Вы писали:
S>В реальном режиме — это под какую ОС?
MS DOS. Приходилось пару раз опускаться на уровень железа. Однажды даже для какого-то проекта русификатор клавиатуры встроенный сделал. Уже не помню, чем там коллег обычный драйвер не устроил. На встроенном ассемблере это оказалось очень просто.
S> Если ассемблер в отдельных файлах, то можно настроить сборку и перевести сами файлы под конкретную платформу. Когда же все намешано внутри C-кода — это ужас.
Так я ж писал: зе беспорядочное использование встроенного ассемблера надо отрывать руки.
S>А если немного синтаксического сахара? К примеру — метки с человеческим именем — ведь в машинных кодах это просто номер ячейки
Метки в ассемблере и так уже с человеческим именем, как и команды. В этом и есть смысл ассемблера — заменить числовые коды на человеческие легко запоминаемые имена.
Ассемблер — это взаимнооднозначное отображение команды ассемблера и ее операндов в машинную команду и операнды.
а вот это
if( eax > ebx ) then
stdout.put("eax > ebx", nl);
endif;
Это что такое? Никак не ассемблер.
С тем же успехом можно выучить наизусть как конструкции С++ переводятся в машинные команды и назвать С++ ассемблером.
Ну конечно у С++ есть оптимизатор поэтому одно и то же может в разные команды переводиться. Хорошо, допустим мы отключаем оптимизатор.
Из статьи про hexagon есть ссылки на всякое про ISA.
МР>По расширению имени файла я предположил было, что это GNU-нотация для ассемблера, но она (как я посмотрел) все же ближе к традиционной <мнемоника>+<операнды>, там отличие от того же Intel в некоторых деталях синтаксиса.
Это действительно ассемблер, просто некоторые из них сделаны чуть более похожими по стилю на C. Названный в соседнем постинге Blackfin ещё ближе к этому (я его сходу не нашёл, но помнил; вспомнил бы сразу, запостил бы про него, а не Hexagon). Вот понравилось кому-то делать ассемблер в другом стиле — не словесные мнемоники, а знаки.
Здравствуйте, Shmj, Вы писали:
S>Вот ранее был типа High-Level Assembler:
Это грубый, неэффективный и тупиковый путь. Годится лишь для упертых фанатов ассемблера. Гораздо эффективнее добавлять доступ к процессорным регистрам и командам в "низкоуровневые ЯВУ" вроде C.
По состоянию на 2025 год я бы ассемблером высокого уровня назвал С. Ну или хотя бы С отнес к языкам среднего уровня. Потому что считать, что С, C#, Java и Python являются языками одного уровня я бы не стал.
Получается по уровням от низкого к высокому что-то вроде
1. Assembler
2. C, возможно JavaScript
3. C#, Java, Python, TypeScript.
S>Вроде чел. делал такой проект, кто помнит?
Был проект С-- (си минус минус) — пишешь почти на C, но в тоже время на асме. Я писал на нём всего пару прог, но ощущение было "как инструмент под задачу пушкабомба". Получалась просто золотая середина между близким к железу и обычным программированием.
Здравствуйте, alpha21264, Вы писали:
A>А зачем? Языки высокого уровня придуманы в 1960-х годах. A>И если ты сейчас пишешь на ассемблере, то и пиши на ассемблере.
Это и есть ассемблер — ты не уходишь от регистров. На ЯВУ — нет прямого доступа к регистрам.
Просто чуть другой формат записи и немного синтаксического сахара.
Здравствуйте, hi_octane, Вы писали:
S>>Вроде чел. делал такой проект, кто помнит? _>Был проект С-- (си минус минус) — пишешь почти на C, но в тоже время на асме.
Зачем?
Макроассемблером вполне можно писать как на высоком языке программирования.
Здравствуйте, Shmj, Вы писали:
S>ассемблерные вставки?
Нет. Ассемблерные вставки — это костыли "от бедности". Правильный путь — псевдопеременные для обращения к регистрам и флагам, intrinsic-функции для выполнения спецкоманд процессора, и т.п.
Здравствуйте, Shmj, Вы писали:
S>Это и есть ассемблер — ты не уходишь от регистров.
Любой язык, идущий "от ассемблера" (то есть, от системы команд), будет по определению архитектурно-зависимым, и с этим ничего не сделать.
Если же идти "от ЯВУ", то даже самые основные средства, вроде intrinsic-функций, реализующих операции, которые есть во многих архитектурах, решают примерно 80% задач, ради которых приходится использовать ассемблер.
Это как с графикой: если она определена в терминах растров, то может предельно эффективно работать на конкретной растровой платформе, но быть лишь очень криво реализуема на каких-нибудь векторных устройствах с полярными координатами. Если же она определена в терминах координат и фигур, то может быть реализована где угодно, с любой желаемой степенью эффективности, и перенесена так же куда угодно, разве что работать попервости будет не так быстро.
S>На ЯВУ — нет прямого доступа к регистрам.
В некоторых есть.
S>Просто чуть другой формат записи и немного синтаксического сахара.
А нету в нем практического смысла. Его еще лет тридцать-сорок назад не было, хотя по инерции продолжали добавлять в ассемблеры псевдоконструкции для условных операций, циклов, автоматическое формирование стековых кадров и прочего. А потом уже остался только один путь — снижать уровень наиболее подходящих ЯВУ. Повышать уровень ассемблера — абсурд.
Здравствуйте, BlackEric, Вы писали:
BE>Получается по уровням от низкого к высокому что-то вроде BE>1. Assembler BE>2. C, возможно JavaScript
Интересная штука, у меня переход на JS вызвал ровно те же ощущения, как в далёком детстве при переходе с Паскаля на Ассемблер. Везде за всем надо следить и тд.
По расширению имени файла я предположил было, что это GNU-нотация для ассемблера, но она (как я посмотрел) все же ближе к традиционной <мнемоника>+<операнды>, там отличие от того же Intel в некоторых деталях синтаксиса.
А больше я с ходу не нашел ничего (а выглядит реально интересно).
это не ассемблер. Ассемблер это машинные команды просто представленные в более удобном для восприятия виде. То есть команда ассемблера = машинная команда.
Здравствуйте, CRT, Вы писали:
CRT>это не ассемблер. Ассемблер это машинные команды просто представленные в более удобном для восприятия виде. То есть команда ассемблера = машинная команда.
А если немного синтаксического сахара? К примеру — метки с человеческим именем — ведь в машинных кодах это просто номер ячейки памяти. Далее — если вместо mov( ebx, eax ); — написать let ebx = eax; — что поменялось? Это тоже команда, просто в более удобном для восприятия виде.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Это грубый, неэффективный и тупиковый путь. Годится лишь для упертых фанатов ассемблера. Гораздо эффективнее добавлять доступ к процессорным регистрам и командам в "низкоуровневые ЯВУ" вроде C.
Т.е. ассемблерные вставки? Еще хуже когда намешано.
Здравствуйте, Shmj, Вы писали:
S>Т.е. ассемблерные вставки? Еще хуже когда намешано.
Я в своё время использовал встроенный ассемблер. В реальном режиме было очень удобно. Не надо было сильно париться с моделями памяти. И о правильной передаче аргументов не надо было думать.
Только, как и с любым другим инструментом, нужно включать голову при использовании. За беспорядочное использование встроенного ассемблера надо руки отрывать. Как сегодня за беспорядочное использование dynamic в Шарпе.
Здравствуйте, Privalov, Вы писали:
P>Я в своё время использовал встроенный ассемблер. В реальном режиме было очень удобно.
В реальном режиме — это под какую ОС?
Тут еще вопрос переносимости. Голый C++|C все-таки не привязан к архитектуре, более-менее соберется под все платформы. Если ассемблер в отдельных файлах, то можно настроить сборку и перевести сами файлы под конкретную платформу. Когда же все намешано внутри C-кода — это ужас.
Здравствуйте, Privalov, Вы писали:
P>MS DOS. Приходилось пару раз опускаться на уровень железа. Однажды даже для какого-то проекта русификатор клавиатуры встроенный сделал. Уже не помню, чем там коллег обычный драйвер не устроил. На встроенном ассемблере это оказалось очень просто.
И зачем после этого было опускаться до запросов на C#? Нужно было так и продолжить на низком уровне.
Здравствуйте, Shmj, Вы писали:
S>И зачем после этого было опускаться до запросов на C#? Нужно было так и продолжить на низком уровне.
Затем, что я работу сменил. Иногда мне приходилось JNI для проекта на Java делать. Тоже низкий уровень. Иногда мне нужно было кое-какие дополнения для виндовых editbox-ов делать.
А C# вспомнил потому, что достался мне в наследство один небольшой проект на нём. И вот там как раз и dynamic, и рефлексия разбросаны по всему коду. Повбывав бы.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А сам встроенный ассемблер — изживать в пользу более внятных языковых средств.
Это про использование всяких функций типа inport/outport и им подобных. Отчасти верно. но во многих случаях использование встроенного ассемблера было удобнее. И если встроенный ассемблер не использовать беспорядочно, то с этим вполне можно было жить. Те, кто работал на более высоком уровне, просто вызывали функцию, не интересуясь, как она сделана.
Здравствуйте, Shmj, Вы писали:
S> Далее — если вместо mov( ebx, eax ); — написать let ebx = eax; — что поменялось? Это тоже команда, просто в более удобном для восприятия виде.
Так приведи примеры для всех команд процессора и посмотрим удобно ли это...
