Чем отличается компилятор от интерпретатора?

может быть, он сначала переводит в машкод, а потом обратно «в себя»?

нет. Потом он отдаёт код процессору. А процессор его выполняет. Т.е. из x+=y; создаётся команда add %eax, %ebx.

Ну, я условно. Все, в любом случае, процессором выполняется. После того, как код выполняется процессором (генерируется строка), выхлоп этого выполнения (строка) подается на вход интерпретатора.

создаётся команда add %eax, %ebx

А почему в асм, а не сразу в двоичное представление?

ну можно так сказать. А компилятор эту «строку» пишет в файл.

создаётся команда add %eax, %ebx

А почему в асм, а не сразу в двоичное представление?

понятно, что сразу в двоичное. Просто асм — взаимо-однозначная(во всяком случае теоретически) запись этого кода. Потому можно и так и так говорить.

На самом деле, в gcc AFAIK есть свой внутренний промежуточный язык, и код сначала в него преобразуется, а уж потом в бинарный код целевой платформы (их тоже больше одной). Теоретически gcc может и интерпретировать, а не только компилировать, чуть подправить нужно, и взлетит. Также и любой интерпретатор можно переделать в компилятор.

Почему?

А компилятор эту «строку» пишет в файл.

Не эту строку, а текст программы (бинарь), генерирующий эту строку.

как раз «бинарь» я и имею ввиду под «строкой».

А я говорил, что на вход интерпретатора подается не этот бинарь, а результат его выполнения (строка, соответствующая синтаксису интерпретатора).

А я говорил, что на вход интерпретатора подается не этот бинарь, а результат его выполнения (строка, соответствующая синтаксису интерпретатора).

«на вход» подаётся текст программы. А «выхода» в явном виде просто нет, т.к. выходной код сразу отсылается в CPU.

код сразу отсылается в CPU.

Да это все фигня, не надо зацикливаться на железе. Допустим, у нас есть строка текста «foo» на языке X. Предположим, что X - компилируемый язык. Транслятор оттранслирует строку в язык Y и запишет в файл. Потом ты можешь исполнить этот файл, и он возвратит куда-нибудь результат своего выполнения [smth]. Предположим теперь, что X - интерпретируемый язык. Транслятор оттранслирует строку в язык Y, затем исполнит получившееся выражение в [smth], и этот [smth] возвратится сразу на вход интерпретатора, в цикл чтения-выполнения-печати. При этом, разумеется, [smth] должен быть синтаксически верным выражением языка X.

Предположим теперь, что X - интерпретируемый язык. Транслятор оттранслирует строку в язык Y, затем исполнит получившееся выражение в [smth], и этот [smth] возвратится сразу на вход интерпретатора

не. выражение [smth] можно прямо так отдать исполнителю.

Так оно и отдается исполнителю сразу, мы же абстрагированы от реализации, когда его рассматриваем. Язык X может быть тем же языком, что и Y, это ничего не меняет по сути. Важно, что результат выполнения выражения возвращается обратно.

В википедии забанили?

Там, кстати, каша полная. Очень многих потом с толку сбивает.

«на вход» подаётся текст программы. А «выхода» в явном виде просто нет, т.к. выходной код сразу отсылается в CPU

То есть touch тоже транслятор — он транслирует имя файла в его открытие.

И mail тоже транслятор. Он транслирует текст письма в команды CPU по отправке этого текста.

И cp тоже транслятор. Транслирует имена файлов в команды CPU по их копированию.

Так?

Теоретически gcc может и интерпретировать, а не только компилировать, чуть подправить нужно, и взлетит.

Не факт. Например для Си нельзя начинать выполнение, пока не оттранслирован весь файл. Поэтому классический интерпретатор «читаем команду, выполняем, читаем следующую» невозможен.

Также и любой интерпретатор можно переделать в компилятор.

Попробуй сделать компилятор picolisp, в котором eval должен получать весь контекст выполнения (потому как вместо макросов fexpr'ы).

То есть touch тоже транслятор — он транслирует имя файла в его открытие.

угу. «Транслятор одной команды».

Не факт. Например для Си нельзя начинать выполнение, пока не оттранслирован весь файл. Поэтому классический интерпретатор «читаем команду, выполняем, читаем следующую» невозможен.

1. очевидно ты путаешь с C++.

2. какая разница, что файл надо читать целиком? Это тут вообще не при чём, как оно файл читает роли не играет.

Попробуй сделать компилятор picolisp, в котором eval должен получать весь контекст выполнения (потому как вместо макросов fexpr'ы).

не вижу проблемы.

не вижу проблемы.

Ну так сделай. Так, чтобы

(de (test x y)
   (eval (read))
   (x y))

Намекну: (eval ...) в picolisp имеет доступ к полному контексту в исходном коде, аналогично #include в C

1. очевидно ты путаешь с C++.

Нет

$ cat test.c
#include <stdio.h>
int main()
{
   printf("%i\n", foo());
}

int foo() { return 5; }
$ gcc test.c
$ ./a.out

какая разница, что файл надо читать целиком

Интерпретатор, согласно определению, выполняет команду сразу после чтения. Для C это невозможно.

угу. «Транслятор одной команды».

Ну тогда все программы, получающие ввод по твоему определению являются трансляторами.

Не-трансляторами являются только команды без входных данных: whoami, yes, true, false, ...

Так?

Что является выходным текстом?

Машкод.

Транслятор — переводчик, переводит текст программы с одного языка (у тебя sh) на другой (машкод). Таким образом, и тот и другой — трансляторы.

Компилятор компилирует, интерпретатор интерпретирует.

Входной текст «df > ~/test». Что является выходным текстом?

Машкод.

Транслятор — переводчик, переводит текст программы с одного языка (у тебя sh) на другой (машкод).

Машкода, эквивалентного алгоритму «прочитать свободное место и записатьв файл ~/test» sh не создаёт. Он при чтении входного текста сразу выполняет поиск файла, перенаправление вывода и запуск в новом процессе команды df. И, опять же, машкод для алгоритма «поиск файла, перенаправление вывода и запуск в новом процессе команды df» не создаётся. В sh вообще нет генерации машкода.

компилировалось в ассемблерный код и работало как в picolisp. Можешь хотя бы просто привести эквивалентный ассемблерный код (ну или C-подобный, если ассемблер не знаешь)

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

Намекну: (eval ...) в picolisp имеет доступ к полному контексту в исходном коде, аналогично #include в C

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

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

бред. С какого перепугу он _должен_?

Да, bash например функции и объявления переменных НЕ выполняет сразу после чтения.

Например:

$ foo() { echo "execute function"; }

как видишь, ничего не выполнилось. Только запомнилось.

В твоём примере тоже можно просто запомнить main(), а выполнить её после определения foo. Где ты узрел проблему?

Ну тогда все программы, получающие ввод по твоему определению являются трансляторами.

«транслятором» является sh, команды получают уже готовый массив с разобранными параметрами. Например rm -rf /* получит массив с именами всех каталогов в корне.

Лор сегодня в ударе.

Компилятор компилирует код в некое промежуточное состояние, которое потом выполняется процессором, интерпретируемый код выполняется интерпретатором, и то и то трансляторы

ЮМашкода, эквивалентного алгоритму «прочитать свободное место и записатьв файл ~/test» sh не создаёт. этот код создавать не нужно, он уже создан, и записан в файле /bin/df, оболочка его просто запускает.

В sh вообще нет генерации машкода.

есть. Там есть сам маш код. Если ты написал (( X = 2+2 )), то будет создан машкод для вычисления 2+2. (скорее всего этот код уже там есть, и записан где-то в switch для всех арифм. операторов).

В школе скорее, в классе 8

Наркомании тред.

(мощность множеств одинаковая)

Мощность множества и его подмножества одинаковы?

этот код создавать не нужно, он уже создан, и записан в файле /bin/df

Там нет части алгоритма «записать в файл ~/test»

Например rm -rf /* получит массив с именами всех каталогов в корне

А дальше считаем этот массив с именами входной программой на языке «rm», а выходной программой считаем удаление каталогов. Значит, транслятор.

В твоём примере тоже можно просто запомнить main(), а выполнить её после определения foo.

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

Мощность множества и его подмножества одинаковы?

для счётного множества: да.

пруф: http://ru.wikipedia.org/wiki/Мощность_множества

А дальше считаем этот массив с именами входной программой на языке «rm»

да. Дальше rm работает как транслятор, и транслирует этот массив во множество системных вызовов unlink(2). А их уже транслирует ядро, а точнее модуль ФС в машкод.

Как-то процессор ведь выполняет этот код?

Во время выполнения кода модифицируется исходный код программы командой (eval (read)). Потом выполняется то, что получилось.

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

int main()
{
    char[1024] code;
    scanf("%s", &code);
    #include code
    print("%s\n", res);
}

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

в принципе это одно и то же. Просто детали реализации и использования.

Дальше rm работает как транслятор ... их уже транслирует ядро ...

Я и говорю, что в таком определении транслятором является любая программа с входными данными

Во время выполнения кода модифицируется исходный код программы командой

это возможно в любом Тьюринг-полном ЯП, ассемблер не исключение.

Всё равно, что в С можно было бы в качестве параметра #include подставлять значение переменной

ты можешь выделить в куче массив, байты в котором будут иметь смысл «команды». Этот массив ты можешь изменять. И выполнять тоже можешь, читая байты специальной функцией execute().

И не трогай препроцессор, он вообще говоря — отдельная сущность. Это что-то вроде предварительной обработки исходного текста, которая делает из двух строк /bin/true Over9000 строчек, которые и компилируются.

Т.е. препроцессор к предмету обсуждения не относится.

Я и говорю, что в таком определении транслятором является любая программа с входными данными

да. формально — да. И даже без данных. /bin/true тоже транслирует себя в код, всегда один и тот же, return 0;

Т.е. препроцессор к предмету обсуждения не относится

Относится. Я утверждаю, что нельзя сделать интерпретатор для языка, где eval имеет мощность не меньше, чем у препроцессора.

В этом случае после ввода пользователя мы получаем другую программу. Для интерпретатора это не препятствие (какая разница, откуда получать следующую команду — от пользователя или из файла), а для компилятора появляется необходимость перекомпилировать новый исходный код, но во время выполнения исходного кода уже нет и компилятора тоже нет, есть только скомпилированная программа.

что нельзя сделать интерпретатор для языка

может s/интерпретатор/компилятор? Согласно Вашему определению?

может s/интерпретатор/компилятор?

Да. Следует читать «Я утверждаю, что нельзя сделать компилятор для языка, где eval имеет мощность не меньше, чем у препроцессора»

а для компилятора появляется необходимость перекомпилировать новый исходный код

зачем? А если в программе есть цикл, который выполняется uint16_t раз, то ты тоже предлагаешь для каждого из 65536и чисел компилировать свой код? Нет, ты сделаешь один цикл.

Открой K&R, там ЕМНИП был пример калькулятора, который вычисляет любые выражения. Без всяких перекомпиляций. Хоть 2+2, хоть (1+4-(8*(4/5)))%6.

Т.ч. eval не нужен. Ну и он вовсе не обязан eval'ить именно тот ЯП, на котором он написан. Вот например eval в sed/perl eval'ит bash'ем. Пример с rm -rf на ЛОРе есть.

Т.ч. eval не нужен.

Существуют языки с таким eval. Picolisp я уже упоминал. Еще в sh можно делать

read a
source $a