compilator & interpretator

это прикол, или провокация флейма? LOL.

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

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

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

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

ок спасибо , в принципе я так и думал .

Ну нифига себе вопросик!

А ещё существуют асемблеры (* чуть не написал ассемблеры *), а что это такое тебе раскажет гугль.

> чуть не написал ассемблеры

И был бы прав.

ага , значит еше ассемблеры есть ?

сколько мне известно аssembler переводит понятный человеку мнемонический код в машинный код например >tasm proga.asm . в случае успеха получаем proga.obj -обьектный файл с машинным кодом который надо еше слинковать типа tlink/t proga.obj

а что такое процесс линковки обьясните plz ?

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

ugoday а что assembler не компилятор ?

tasm proga.asm - правильно переводится в машинный код , также просчитываются адреса процедур подставляются и преобразуются различные там d и b в h . и т.д.

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

> а что такое процесс линковки обьясните plz ?

Есть у тебя в твоих .c файлах для примера функции, которые перекрестно вызываются из других файлов, и так же вызываются функции из библиотеки.

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

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

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

Сорри за кривой ответ, но лучше поискать в литературе - описанная схема примерная, реализации могут варьироваться.