Подскажите хорошую литературу по низкоуровневым языкам.

[warlock66613]

arseniiv в сообщении #1162293 писал(а):

в них не очень удобно засовывать весь код, который должен выполняться, когда распарсится та или иная конструкция языка

Скорее даже невозможно, чем неудобно, хотя бы потому, что языки программирования не являются контекстно-свободными и многие проверки корректности можно выполнить только имея AST целиком.

[realeugene]

warlock66613 в сообщении #1162309 писал(а):

arseniiv в сообщении #1162293 писал(а):

в них не очень удобно засовывать весь код, который должен выполняться, когда распарсится та или иная конструкция языка

Скорее даже невозможно, чем неудобно, хотя бы потому, что языки программирования не являются контекстно-свободными и многие проверки корректности можно выполнить только имея AST целиком.

Формально всю обработку дерева можно поместить в действие стартового правила.

[Dmitriy40]

mustitz в сообщении #1162197 писал(а):

Но всё это ушло далеко в прошлое и не вернёться уже никогда. Так что надо признать, что либо низкоуревневое программирование вымерло как класс на сегодня, либо немного раздвинуть его рамки.

Как занимающийся именно таким вот низкоуровневым программированием сразу под несколько разных микроконтроллеров (в том числе и полностью на ассемблере) могу смело утверждать что не вымерло. Даже под х86 код на асме (например в виде C/C++ Intrinsic) ещё встречается в некоторых сильно оптимизированных библиотеках и внутренних циклах расчётных программ.

[arseniiv]

realeugene
Но удобно ли это будет с точки зрения разработки? Редакторов/IDE для чистого кода на языке, файл на котором генерирует генератор (упс), очевидно, больше, чем поддерживающих смешанный код в формате этого генератора. Ну хоть отладка: конечно, можно всё это делать с результатом работы генератора, но исправления-то вносить надо будет не в него.

[Chifu]

arseniiv в сообщении #1162036 писал(а):

... Интерпретации уж точно тут никакой.

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

Цитата:

Вы так и не аргументировали это сколько-нибудь ясным образом. Я не вижу, в чём мои определения конкретно плохи, а ваши — правильны. Вы просто что-то изложили, и в этом тексте я аргументы вычленить, увы, не в состоянии.

А где ваши определения? Вы почему-то уходите в частности, по моему принцип прозрачный, в Вики буквально по одному предложению. И вообще я отвечал на сообщения о Форт-системе, а не в общем про современные программные системы. В литературе Форт так и называют интерпретирующей системой с шитым кодом. Идея компиляции слов проста - подготовить их для скорейшего выполнения интерпретатором, чтобы ему при вызове слова не надо было транслировать статью определения слова.

[arseniiv]

Chifu в сообщении #1162364 писал(а):

ОС ожидает и интерпретирует ввод, она решает (на уровне ОС) что делать с файлами, пока не вышли из ОС - это и есть интерпретация, но конечно же не в смысле трансляции кода языка высокого уровня в машинный код.

Вот именно. Давайте не вводить неуместных обобщений. Здесь говорилось пока лишь о коде.

Chifu в сообщении #1162364 писал(а):

Интерпретатор обрабатывает ввод, запросы, продолжая работать, т.е. после выполнения запроса управление передается интерпретатору.

Когда я запускаю cmd something.bat, после выполнения something.bat управление никуда не передаётся. Процесс cmd.exe завершается. Хотя, конечно, можно и передавать, если дописать кое-какие аргументы (какие — не помню). От этого cmd.exe не перестаёт быть интерпретатором.

Chifu в сообщении #1162364 писал(а):

А где ваши определения?

Интерпретатор исполняет код «сам», компилятор превращает код в другой код (и может потом попросить исполнить результат кого-нибудь ещё). И всё, никакой метафизики и путаницы c read-eval-print loop.

Chifu в сообщении #1162364 писал(а):

И вообще я отвечал на сообщения о Форт-системе, а не в общем про современные программные системы.

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

[Chifu]

arseniiv в сообщении #1162391 писал(а):

Когда я запускаю cmd something.bat, после выполнения something.bat управление никуда не передаётся. Процесс cmd.exe завершается. Хотя, конечно, можно и передавать, если дописать кое-какие аргументы (какие — не помню). От этого cmd.exe не перестаёт быть интерпретатором.

Ладно, про завершения я для себя сократил: пока команды командного файла (ввод) не закончились (т.е. интерпретатор выполнял их "сам"), управление возвращалось в интерпретатор команд, когда ввод закончился итерпретатор завершил работу. Чтобы дальше выполнять команды командного файла (ввод) надо опять запустить интерпретатор команд.

[arseniiv]

Chifu в сообщении #1162459 писал(а):

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

Это в случае cmd вам так везёт, что bat-файл — почти не более чем сумма своих строк-команд, и что куча стандартных команд (но не все) на самом деле вызовы одноимённых программок. А вот в случае скомпилированного кода для LuaVM говорить, что для каждой инструкции управление уходит от и возвращается к интерпретатору (виртуальной машине), просто дико.

-- Пн окт 24, 2016 11:38:52 --

Chifu в сообщении #1162459 писал(а):

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

Я уже окончательно запутался, что это должно значить. Лишь недавно вы говорили, что это отличительная черта компилятора — он заканчивает, его надо запускать. А интерпретатор не заканчивает, а переспрашивает. А теперь он не переспрашивает и заканчивает. Истина где-то рядом…

[Chifu]

arseniiv в сообщении #1162466 писал(а):

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

А что там с LuaVM? Вероятно есть код интерпретатора, который вызывается всякий раз когда обращаются к интерпретатору.

[Chifu]

arseniiv в сообщении #1162466 писал(а):

Я уже окончательно запутался, что это должно значить. Лишь недавно вы говорили, что это отличительная черта компилятора — он заканчивает, его надо запускать. А интерпретатор не заканчивает, а переспрашивает. А теперь он не переспрашивает и заканчивает. Истина где-то рядом…

Я так начинал:

Chifu в сообщении #1161686 писал(а):

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

Если вас смущает, то что интерпретатор в отсутствии ввода завершает работу, то объедините весь ввод, обрабатываемый таким интерпретатором в один ввод, тогда работа интерпретатора будет непрерывной. Т.е. интерпретатор вызывается по мере надобности, но для этого код интерпретатора должен всегда быть доступным.

[Dmitriy40]

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

[arseniiv]

Chifu в сообщении #1162476 писал(а):

А что там с LuaVM? Вероятно есть код интерпретатора, который вызывается всякий раз когда обращаются к интерпретатору.

Или я вас неправильно понимаю, или это трюизм. Да, мы «обращаемся к интерпретатору» с байт-кодом, и он его потом усердно выполняет, до самого конца не останавливаясь и ничего не спрашивая, если только не наткнётся на пользовательскую функцию, что бывает, когда Lua используется как библиоека другой программой, но зря я это сказал, т. к. лес и так достаточно густой.

Chifu в сообщении #1162518 писал(а):

Если вас смущает, то что интерпретатор в отсутствии ввода завершает работу, то объедините весь ввод, обрабатываемый таким интерпретатором в один ввод, тогда работа интерпретатора будет непрерывной. Т.е. интерпретатор вызывается по мере надобности, но для этого код интерпретатора должен всегда быть доступным.

Меня смущает не это, но я не собираюсь пытаться тут точно вербализовать, что именно, потому что это тут оффтоп.

-- Пн окт 24, 2016 19:48:49 --

Dmitriy40 в сообщении #1162534 писал(а):

Не пойму сколько можно спорить об очевидном?

+много. Мне лично уже надоело.