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

[Pavia]

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

Ага, особенно когда есть стандарт языка и компиляторы стараются его придерживаться.

В том то и дело, что даже стандартов Си куча. И в последнем одобрели сборку мусора. И думаю на этом бюрократы неостановятся. А что у Си с ООП? Так что есть у меня есть сомнения. Можноли современный Си отнести к языкам низкого уровня или нет.

[Xaositect]

Pavia в сообщении #1161737 писал(а):

В том то и дело, что даже стандартов Си куча. И в последнем одобрели сборку мусора. И думаю на этом бюрократы неостановятся. А что у Си с ООП? Так что есть у меня есть сомнения. Можноли современный Си отнести к языкам низкого уровня или нет.

Стандартов C четыре штуки, и их, в отличие от стандартов C++, можно даже прочитать и усвоить. Сборки мусора нет (Вы путаете с C++11, но и там она не обязательна и, насколько я знаю, реализована только в MSVS).

Объектно-ориентированность и низкоуровневость ортогональны (см. Объектно-ориентированное программирование на ассемблере). На С тоже можно делать ООП в стиле С++, для этого нужны структуры + указатели на функции + указатели на неполные типы для инкапсуляции. С ООП в стиле Smalltalk сложнее.

[iifat]

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

iifat в сообщении #1161615 писал(а):

Позже появились Форт-системы с компиляцией в код процессора

Эта странная фраза возможно указывает на то что до этого Форт-система в основном использовалась как интерпретатор (а компилятор появился позже)

Эта странная фраза, возможно, указывает на то, что до этого Форт был чорным властелином, поработившим Землю и окрестности. Хотя я-то имел в виду всего лишь что до этого Форт-системы компилировали слова не в код процессора.
По-вашему, массив функций превращает программу в интерпретатор? Прощайте все компиляторы ООП-языков...

[Chifu]

iifat в сообщении #1161829 писал(а):

... По-вашему, массив функций превращает программу в интерпретатор? Прощайте все компиляторы ООП-языков...

Прочитайте:

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

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

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

Цитата:

Хотя я-то имел в виду всего лишь что до этого Форт-системы компилировали слова не в код процессора.

Если программа транслируется не в машинный код, то этот результат трансляции далее выполняется либо интерпретатором (промежуточного кода) не выходя из интерпретатора (например из Форт-системы), либо компилируется в файл для выполнения в любое время в операционной системе. Из моих определений видно, что Форт-система может работать как в режиме интерпретации, так и в режиме компиляции программы, а так же что такое компиляция слова из понимания того, что в этом процессе не происходит выхода из системы программирования (необходима интерпретация слов).
Вики: Шитый код (threaded code) — один из способов реализации промежуточной виртуальной машины при интерпретации языков программирования (наряду с байт-кодом).

[mustitz]

Как по мне, чтобы быть низкоуровневым, языку программирования надо две вещи. Во-первых, это близость к архитектуре. Конено, с памятью можно работать при помощи функций PEEK и POKE (привет Z80), но вот только этот путь неэффектиный. Опять же, TSS, таблицы дескрипторов, конфигурационое пространство PCI должны быть доступны через механизмы, подобные структурам, для максимальной эффективности. Во-вторых, язык должен предоставлять эффективную возможность взаимодействия с другими уровнями, потому как нижний подразумевает верхний как минимум, не говоря о промежуточных.

В теории этим условиям удовлетворяет достаточно большое количество языков, которые могут быть использованы как низкоуровневые. Например, C# с использованием unsafe, Delphi, ... Но на практике взаимодействие с другими уровнями это большая рутинная задача, которая останавливает использование. В своё время я писал загрузчик дискеты, который загружал программу на паскале, которая грузила Windows DLL в память, переключалась в защищённый режим и выполняла long jump на метод из этой DLL, который вешался на IRQ0 и IRQ1, печатал скан-коды клавиш и что-то по таймеру рисовал. Дело нехитрое, но вот написать что-то серьёзное (хотя бы драйвер для Windows/Linux) — возникает вопрос взаимодействия с другими уровнями, которые уже написаны на C, имеют интерфейсы на C, которые надо переводить долго, нудно и непонятно зачем. В силу совместимости с С, язык C++ может реально использоваться для низкоуровневого программирования (и используется). А Delphi/Pascal пока чисто теоретически, пока кто-нить не реализует биндинги.

[Chifu]

Вики: Низкоуровневый язык программирования (язык программирования низкого уровня) — язык программирования, близкий к программированию непосредственно в машинных кодах используемого реального или виртуального (например, Java, Microsoft .NET) процессора. Для обозначения машинных команд обычно применяется мнемоническое обозначение. Это позволяет запоминать команды не в виде последовательности двоичных нулей и единиц, а в виде осмысленных сокращений слов человеческого языка (обычно английских). ...
Как правило, использует особенности конкретного семейства процессоров. Общеизвестный пример низкоуровневого языка — язык ассемблера, хотя правильнее говорить о группе языков ассемблера. Более того, для одного и того же процессора существует несколько видов языка ассемблера. Они совпадают в машинных командах, но различаются набором дополнительных функций (директив и макросов).
Также к языкам низкого уровня условно можно причислить CIL, применяемый в платформе Microsoft .NET, Форт, Байт-код Java.

Вики: Высокоуровневый язык программирования — язык программирования, разработанный для быстроты и удобства использования программистом. Основная черта высокоуровневых языков — это абстракция, то есть введение смысловых конструкций, кратко описывающих такие структуры данных и операции над ними, описания которых на машинном коде (или другом низкоуровневом языке программирования) очень длинны и сложны для понимания.
Высокоуровневые языки программирования были разработаны для платформенной независимости сути алгоритмов. Зависимость от платформы перекладывается на инструментальные программы — трансляторы, компилирующие текст, написанный на языке высокого уровня, в элементарные машинные команды (инструкции). Поэтому, для каждой платформы разрабатывается платформенно-уникальный транслятор для каждого высокоуровневого языка, например, переводящий текст, написанный на Delphi в элементарные команды микропроцессоров семейства x86.
Так, высокоуровневые языки стремятся не только облегчить решение сложных программных задач, но и упростить портирование программного обеспечения. Использование разнообразных трансляторов и интерпретаторов обеспечивает связь программ, написанных при помощи языков высокого уровня, с различными операционными системами программируемыми устройствами и оборудованием, и, в идеале, не требует модификации исходного кода (текста, написанного на высокоуровневом языке) для любой платформы.
Такого рода оторванность высокоуровневых языков от аппаратной реализации компьютера помимо множества плюсов имеет и минусы. В частности, она не позволяет создавать простые и точные инструкции к используемому оборудованию. Программы, написанные на языках высокого уровня, проще для понимания программистом, но менее эффективны, чем их аналоги, создаваемые при помощи низкоуровневых языков. Одним из следствий этого стало добавление поддержки того или иного языка низкого уровня (язык ассемблера) в ряд современных профессиональных высокоуровневых языков программирования.
Примеры: C++, C#, Delphi, Fortran, Java, JavaScript, Лисп, Паскаль, PHP. Языкам высокого уровня свойственно умение работать с комплексными структурами данных. В большинстве из них интегрирована поддержка строковых типов, объектов, операций файлового ввода-вывода и т. п. ...

[arseniiv]

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

Прочитайте:

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

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

Нет. Первое — это REPL, и он ортогонален интерпретации/компиляции; можно интерпретировать файл целиком и ничего по окончании выполнения не спрашивать (куча примеров, хоть те же shell scripts, коим лет сто). Второе — это слишком узко для компиляции. Сохранять в файл необязательно, можно компилировать в область памяти. К тому же, можно компилировать не в машинный код, а в байт-код или в код на высокоуровневом языке. Или вам придётся ввести для этих вещей новый термин (трансформировать?). Можно ещё JIT-компилировать (just-in-time compilation), когда программа содержит промежуточный код, компиляция которого в машинный вызывается при её запуске, а после компиляции управление передаётся скомпилированному коду.

[Chifu]

Можно интерпретировать файл целиком (вообще-то не важен размер интерпретируемого текста, целиком - это характеристика законченности программы), но далее либо создается исполняемый файл и можно выйти из транслятора (программа готова для независимого исполнения в операционной системе), либо оставаться в системе программирования и продолжать"накапливать" определения слов, которые выполняются интерпретатором. Трансляция слов в промежуточный код является компиляцией, а выполнение слов интерпретатором - интерпретация. Спрашивает или нет программа - относится к её действию, а не то как она транслируется. Операционная система по своей структуре является интерпретатором, т.е. ОС интерпретирует все созданные файлы, выход из ОС это завершение работы. Не важно где хранится файл в памяти или на диске, главное вышли мы или нет из транслятора (системы программирования) или нет. Если мы создаем промежуточный код, то далее ситуация повторяется до создания исполняемого файла. Исполняемый компилированный файл может состоять из промежуточного кода и процедуры интерпретации этого кода в одном файле - получение такого независимого от системы-интерпретатора файла является компиляцией, а выполнение этого файла разворачивается в интерпретацию промежуточного кода процедурой интерпретации. Т.е. основной принцип - выходим мы из транслятора или нет. Отладка программы в IDE-компиляторе это компиляция программы в машинный код в диалоговом режиме. Трансляция это или компиляция, или интерпретация.

[arseniiv]

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

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

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

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

Не важно где хранится файл в памяти или на диске

Просто «файл в памяти» это уж больно специфическое для текущего уровня рассмотрения понятие. Да, в некоторых ОС некоторые области памяти ведут себя как файлы и так зовутся, но вообще правильнее будет «не важно, где хранится результирующий код», файл — это слишком конкретно.

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

Т.е. основной принцип - выходим мы из транслятора или нет.

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

[Munin]

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

Первое — это REPL

Спасибо, теперь я знаю, как это называется!

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

Операционная система по своей структуре является интерпретатором

Это представление об ОС на уровне MS-DOS. В операционных системах интерпретатором является отдельная подсистема - командная оболочка (shell).

[mustitz]

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

Вики: Низкоуровневый язык программирования (язык программирования низкого уровня) — язык программирования, близкий к программированию непосредственно в машинных кодах используемого реального или виртуального (например, Java, Microsoft .NET) процессора.

Мне кажеться, что на сегодня это определение достаточно устарело. Разделение на низкий и высокий уровень осталось, а вот средства программирования изменились кардинально. Сегодня практически не встретишь программирование на ассемблере в чистом виде, хотя это не освобождает от знания архитектуры. Про JVM и .NET английская версия умалчивает — “low-level languages are sometimes described as being "close to the hardware".”

[mustitz]

realeugene в сообщении #1161662 писал(а):

Язык С низкоуровневый, потому что на нём сложно писать высокоуровневый код.

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

[realeugene]

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

На голом C реализовано много больших и сложных систем.

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

[mustitz]

iifat в сообщении #1161701 писал(а):

Низкоуровневость Цэ в том, что mustitz не застал ни автокодов, ни ассемблеров, да к тому же путает низкоуровневость с вкусами некого «коммьюнити» и вакансиями работодателей.

Немного застал, и помахал им ручкой. Некоторый опыт в программировании в кодах для Z80 и MOS Technology 6502 есть. Под x86 приходилось писать на ассемблере. Но всё это ушло далеко в прошлое и не вернёться уже никогда. Так что надо признать, что либо низкоуревневое программирование вымерло как класс на сегодня, либо немного раздвинуть его рамки.

-- 23.10.2016, 12:57 --

realeugene в сообщении #1162196 писал(а):

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

Это древний и во многом достаточно субъективный холивар. Результаты двойных слепых экспериментов на эту тему я не знаю.

-- 23.10.2016, 13:10 --

Pavia в сообщении #1161712 писал(а):

Браво! Холивар на пустом месте.
Что касается Си, то к низкоуровневым языкам его отнесли его-же создатели в книге K&R.

Просто он почти один в один ложился на архитектуру PDP-11, читай один оператор C — одна команда процессора.

-- 23.10.2016, 13:21 --

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

Но неудобнее, чем на языках, где поддерживаются, скажем, GADT. Или сборка мусора. Или хотя бы просто generics.

Ну... трансляторы удобнее писать при помощи генератора синтаксических анализаторов типа GNU Bison или ANTLR. Бизон, кстати, написан на C. Вопрос удобства, опять же, субъективный. Лично мне разбираться с кодом GCC (чистый C) было куда проще, чем с кодом LLVM (матёрый C++ с кучей шаблонной магии).

[arseniiv]

Я особо не пользовался вещами типа Bison или ANTLR, которые генерируют код парсера, но мне кажется, в них не очень удобно засовывать весь код, который должен выполняться, когда распарсится та или иная конструкция языка. Удобнее может быть всё-таки просто выдать какую-то информацию (очередной кусок синтаксического дерева, скажем), а код, написанный вручную (не сгенерированный такой штукой) уже будет этим пользоваться. Так что это будет только часть транслятора, фактически парсер, возможно, с чем-то ещё кроме этого. А на парсере-то всё только начинается… Например, если у языка достаточно развёрнутая статическая система типов, всё-таки было бы неплохо уметь с ними обращаться по-простому. GADT для этого обычно самое то.

-- Вс окт 23, 2016 20:39:11 --

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

Лично мне разбираться с кодом GCC (чистый C) было куда проще, чем с кодом LLVM (матёрый C++ с кучей шаблонной магии).

Так то ж C++. По модулю соответствующего холивара, это не самый лучший пример.