Средство для программирования контроллера: Си или МЭК 61131?

Можно ссылаться на любые источники, левые, правые.

Но ИНТЕРПРИТАТОР, это программа которая налету транслирует исходный текст программы и тут же его исполняет. Я приводил пример BASIC? на заре PC.

КОМПИЛЯТОР сначало переводит в натив, потом исполняй его сколько хочешь.

Все это не из какихто, бумажных источников, а сам писал на них и на разных платформах.  ПОВЕРЬТЕ!!!

Mike_K Но ИНТЕРПРИТАТОР, это программа которая налету транслирует исходный текст программы и тут же его исполняет. Я приводил пример BASIC? на заре PC.

Если Вы вбиваете текст, и хотите чтобы он тут же исполнялся, то другого пути и нет. Для калькуляторов - то что надо, и для командных интерпретаторов - тоже в самый раз.

Однако, какое это имеет отношение к PLC? Для него программа обычно подготавливается кроссовой системой, а потом загружается в PLC и исполняется как единое целое.  Нет никакого смысла хранить программу в PLC в виде исходного текста. Поэтому так никто и не делает, кроме, возможно, каких-то специальных случаев, или если разработчик - совсем уж недотепа :-)

Кроссовая система компилирует программу, а в PLC она хранится и исполняется в виде "байт-кода". Дополнительно компилировать ее больше не надо, она "готова к употреблению" и исполняется интерпретатором "как есть" безо всякой дополнительной трансляции.

Чтобы было понятнее, точно так же работает Java, см http://java.about.com/library/glossary/bldef-interpreter.htm

The Java interpreter (java) decodes and executes bytecode for the Java Virtual Machine (JVM). See compiler, runtime system.

http://java.about.com/library/glossary/bldef-compiler.htm

The Java compiler (javac) translates source code written in the Java language into bytecode to be run on the Java Virtual Machine (JVM). See interpreter.

Здесь вы ни слова не найдете о том, что Java интерпретатор транслирует байткод. Если верить некоторым упертым "специалистам", то интерпретатор Java - это вообще не интерпретатор, а невесть что, поскольку он не укладывается в их допотопные определения и "не от мира сего" представления об интерпретаторах ;-)

Кстати, надо подчеркнуть, что движущие мотивы при создании Java были очень схожи с теми, из-за которых в большинстве PLC используется именно интерпретаторы.

Владимир Е. Зюбин интерпретатор всегда имеет дополнительные расходы на трансляцию во время исполнения.

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

Я привел  два конкретных примера интерпретаторов, которые ничего не транслируют при исполнении: SPF и Java. Я мог бы еще упомянуть классический p-код, но очень опасаюсь, что Вы про него ничего не слышали, а мои скромные, но правдивые объяснения, встретите с недоверием.

Могу Вас уверить, что подавляющее большинство PLC тоже ничего не транслируют, а исполняет заранее оттранслированный байт-код.

Ради повышения образования, можете глянуть на описание и исходные тексты интерпретируюшей системы BASIC в компьютере Atari, http://www.ping.be/kim-1__6502/6502/absb.html  Если Вы способны читать по-аглицки, Вы увидите, что уже в 1978 году эта система использовала тот самый "трюк", который я пытаюсь Вам втолковать:

A more accurate term for Atari's BASIC Language Translator is pre-compiIing interpreter.

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

Кроме того, из приведенных примеров один - SPF - практически не имеет накладных расходов даже на исполнение оттранслированного кода. Однако у меня создалось впечатление, что этот факт оказался недоступен Вашему пониманию.

Владимир Е. Зюбин можно выискивать блох, как это Вы пытаетесь делать в моей статье...

Видите ли, дело совсем не в "блохах". Вам потребуется какое-то время, чтобы произвести соответствующую корректировку Ваших определений и понятий. Действительно, на первый взгляд разница между тем, что Вы говорите, и тем, что есть на самом деле, кажется незначительной и несущественной.  Однако я вполне уверен, что впоследствии Вы увидите к каким серьезным переменам во взглядах и выводах Вы будете вынуждены прийти после такой вынужденной корректировки. На это потребуется время, я Вас не тороплю.

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

Кроме того, хочется надеяться, что в результате дискуссии Вы прониклись большим почтением к LD и FBD, поскольку лучше увидели их глубинную связь с функциональными языками. Заодно, наверное, рассеялось Ваше ошибочное представление о том, что лямбда-калькулус является необходимой основой для функциональных языков.