LINUX.ORG.RU

Интерпретация, компиляция, а это что?

 ,


1

2

Если транслятор преобразовывает программу:

input i
let j = i * 2;
print j

в

#include "set_val.h"
hash vars;
int main()
{
   input("i");
   set("j", mult(val("i"), 2);
   print(val("j"));
}

где set, mult и val определены как

void set(char *key, variant & val)
{
   set_hash(vars, key, val);
}

variant val(char *key)
{
   return get_hash(vars, key);
}

variant mult(variant a, variant b)
{
   variant c;
   assert(a.type == NUMBER && b.type == NUMBER);
   c.type = NUMBER;
   c.number = a.number * b.number;
}

а затем при помощи gcc получает бинарник, то этот весь процесс является компиляцией или интерпретацией?

★★★★★

Последнее исправление: maxcom (всего исправлений: 1)
Ответ на: комментарий от wota

http://ru.wikipedia.org/wiki/%D0%A2%D1%80%D0%B0%D0%BD%D1%81%D0%BB%D1%8F%D1%82%D0%BE%D1%80

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

Весь процесс - компиляция, твой язычок в Си - трансляция.

Kuzy ★★★
()
Ответ на: комментарий от Kuzy

Весь процесс - компиляция

Меня смущает то, что в скомпилированной программе все обращаенияк переменным исходной программы являются чтением/записью в хэш.

Если брать формализм «транслятор, который преобразует программы в машинный язык», то можно и старый clipper считать компилятором: он умел упаковать в один файл интерпретатор и исходный код программы. Файл, естественно, получался .exe.

monk ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

А если из бинарника в эквивалентный исходник, это трансляция или декомпиляция? (Интересна правильная терминология).

i-rinat ★★★★★
()
Ответ на: комментарий от tailgunner

Source-to-source translation

Я не в этом контексте. Если бы результатом трансляции было

int main()
{
   int i, j;
   input_int(&i);
   j = i * 2;
   print_int(j);
}
то это была бы однозначная компиляция с промежуточным представлением (как первые C++ компиляторы сначала транслировали в C, а уже потом в машинный код).

А вот когда переменные как-бы интерпретируются... я в сомнениях.

monk ★★★★★
() автор топика
Ответ на: комментарий от i-rinat

А если из бинарника в эквивалентный исходник

В учебниках, которые я читаю, о такой трансляции не пишут, поэтому Ъ кошерного термина я не знаю :)

tailgunner ★★★★★
()
Ответ на: комментарий от monk

А вот когда переменные как-бы интерпретируются... я в сомнениях.

Термин source-to-source описывает вход и выход транслятора. «Интерпретируются» ли переменные (что бы это не значило) - нерелевантно; то, что исходный язык динамически типизированный, использует не-лексические области видимости или экзотичен в еще каком-то отношении - тоже нерелевантно.

tailgunner ★★★★★
()
Ответ на: комментарий от monk

Нет, они не интерпретируются, это один из способов привязки значения к переменной (в CL, например, в общем случае делается примерно также symbol -> value).

staseg ★★★★★
()
Последнее исправление: staseg (всего исправлений: 1)

Добавлю к вышеотписавшимся - кодогенерация

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от tailgunner

В учебниках, которые я читаю, о такой трансляции не пишут

Да и в гугле она плохо ищется. Обычно находится только «такое сделать невозможно».

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Обычно находится только «такое сделать невозможно»

Частный случай 1: выташить исходник из исполняемого файла полученного из среды Clipper

Частный случай 2: дизассемблирование

monk ★★★★★
() автор топика
Ответ на: комментарий от staseg

в CL, например, в общем случае

В результате компиляции SBCL — нет, а clisp считают интерпретатором.

monk ★★★★★
() автор топика
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от monk

В результате компиляции SBCL — нет

Даже динамические переменные? Все зависит от реализации, ничто не запрещает и лексические переменные искать в рантайме как-нибудь вроде (lookup symbol context). ECL (который как раз траслирует лисп в С и затем компилирует его — и тоже называется компилятором) делает именно так как минимум в большинстве случаев (оптимизатор там аховый).

staseg ★★★★★
()
Последнее исправление: staseg (всего исправлений: 1)
Ответ на: комментарий от monk

дизассемблирование

Ближе вот к этому. Только цель в запуске бинарника собранного под один CPU на CPU с другой архитектурой. Что-то вроде бинарной трансляции, но выполненной один раз, статически.

i-rinat ★★★★★
()
Ответ на: комментарий от monk

А вот когда переменные как-бы интерпретируются

А что понимается под интерпретированием переменных в примере ТС-а?

Corey
()
Ответ на: комментарий от staseg

То, что они скомпилировались не в адрес в памяти, а в хеш-таблицу.

А какая разница, есть там эта таблица или нет? Эта таблица является лишь реализацией scope для транслируемого языка. Единственное, что наталкивает на мысли об интерпретации, так это рантайм проверки типов... но ведь и в c++ и в java можно использовать RTTI, от этого они интерпретируемыми языками вроде как не становятся.

Corey
()
Ответ на: комментарий от Corey

Ага. А самая мякота в том, что и сам компилятор Си может сгенерировать код с динамическим скопом, насколько я знаю, стандарт эти вещи не оговаривает.

staseg ★★★★★
()
Ответ на: комментарий от Corey

Ну я не нашел там требований представления переменных.

staseg ★★★★★
()

Интерпретация, очевидно

anonymous
()

Это компиляция. Компиляция с языка S на язык P — это процесс построения такой программы на языке P, которая работает «так же», как и заданная программа на языке S.

buddhist ★★★★★
()

Читайте забытых советских классиков. Турчина в данном случае.

anonymous
()

А constant folding в современных компиляторах это что тогда?

anonymous
()
Ответ на: комментарий от buddhist

Компиляция с языка S на язык P — это процесс построения такой программы на языке P, которая работает «так же», как и заданная программа на языке S.

То есть интерпретация — частный случай компиляции? Ведь если есть интерпретатор языка S, написанный на языке P (и язык P поволяет задавать строковые константы в тексте программы), то очевидно, что можно исходники программы просто внести как начальные данные в код интерпретатора.

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

Да, компиляция — это специализация интерпретатора по конкретным данным, а компилятор — это специализатор, специализированный по интерпретатору.

buddhist ★★★★★
()

преобразовывает

После этого, не читал

robot12 ★★★★★
()
Ответ на: комментарий от anonymous

Futamura projection

Прикольно. Значит у меня есть компилятор SQL. И компилятор программ на bash... :-)

monk ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Да ну? Слабо четко сформулировать, в чем разница?

ну я попробую

если результатом трансляции является не полностью специализированный интерпретатор, то транслятор является интерперетатором, иначе — компилятором

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

Как полноту специализации мерять? Процент не изменившегося при специализации кода исходного интерпретатора?

anonymous
()

я предположу следующее:

если результатом трансляции является не полностью специализированный интерпретатор, то транслятор является интерперетатором, иначе — компилятором

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

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

теперь опять *предположим*, что компилятор с++ скомпилирует твою первую версию вот так:

void do_main(const char* name1, const char* name2) {
   input(name1);
   set(name2, mult(val(name1), 2));
   print(val(name2));
}
int main() {
  const char* name1 = "i";
  const char* name2 = "j";
  do_main(name1, name2);
  return 0;
}

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

даже если do_main будет заинлайнена, но заинлайненный код позволит себя вызывать с разными name1 и name2, то по-прежнему специализация будет не полной

чуть более полной специализация будет, если компилятор с++ посчитает хэши строк «i» и «j» во время копиляции, однако и тогда останется возможность вызова do_main(name1, name1):

void do_main(hash_value name1, hash_value name2) {
   input_by_hash_value(name1);
   set_by_hash_value(name2, mult_by_hash_value(val_by_hash_value(name1), 2));
   print(val_by_hash_value(name2));
}
int main() {
  hash_value name1 = 0x24545723; // hash_of("i")
  hash_value name2 = 0x70FFA292; // hash_of("j")
  do_main(name1, name2);
  return 0;
}

p.s. ты забыл минимум одну скобку в своем коде

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от anonymous

Расскажи ка вот что. Какое практическое значение имеет знание того, чем является конкретная программа — интерпретатором или компилятором?

crowbar
()
Ответ на: комментарий от anonymous

Как полноту специализации мерять?

это хороший вопрос, см. мои размышления чуть выше

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от crowbar

Расскажи ка вот что. Какое практическое значение имеет знание того, чем является конкретная программа — интерпретатором или компилятором?

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от crowbar

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

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

www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 2)

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

Dron ★★★★★
()
Ответ на: комментарий от monk

Если брать формализм «транслятор, который преобразует программы в машинный язык», то можно и старый clipper считать компилятором: он умел упаковать в один файл интерпретатор и исходный код программы. Файл, естественно, получался .exe.

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

goingUp ★★★★★
()
Ответ на: комментарий от tailgunner

Раскрой тему жручести памяти.

это достаточно большая и непростая тема, особенно из-за того, что, как я написал выше, «не исключено, что более специализированная программа будет жрать существенно больше памяти, чем недоспециализированная»

но я начну

1. недоспециализированная часть это фактически невырезанный кусок интерпретатора; как и любая прога (особенно написанная в стиле ооп) он жрет память на инициализированные данные (да, можно эти данные инициализировать лениво, но это приведет к тормозам, если они внезапно все же окажутся нужны) и на runtime-данные (особенно если он пытается еще и jit-ить, гы-гы)

2. если попроще — то специализация позволяет заменить хэши на линейные массивы, выбросив вообще ключи хэша

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от crowbar

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.