История изменений
Исправление quasimoto, (текущая версия) :
Когда транслятор зацикливается
Трансляторы не зацикливаются. И да, в этих вопросах ты точно теоретик-кун :) Ну то есть ты даже не представляешь как циклы компилируются на уровне манипуляций которые компилятор производит — апостериори только смотришь на вход и выхлоп. Посмотри хотя бы http://llvm.org/docs/tutorial/LangImpl5.html#for-loop-expression.
Сегодня таких интерпретаторов не бывает. Сейчас интерпретатор как и компилятор обрабатывает _весь_ цикл, а уж потом его исполняет, когда полностью до конца распарсит.
Ты путаешь, но подожди — я тебе ниже вопрос задам.
транслятор ... Если это тупой интерпретатор
Книжек не читай @ свои определения придумывай :/
Т.е. компилятор сначала просматривает цикл, а потом его переводит в машкод, и его записывает на диск. Интерпретатор делает также, однако этот код никуда не пишет, а просто выполняет.
Ну, допустим, компилятор переводит — можно и даже нужно результат сохранять, так как это и есть назначение компилятора. Интерпретатор — нет, какое нафиг «код никуда не пишет», если у него нет никакого кода, только выполнение (а это назначение интерпретатора).
это особенности реализации. Команда HLT вообще не имеет отношения к алгоритмам.
ЩИТО? L ::= (PLS | DBL | JMP Number | HLT)* — грамматика языка в вопросе, изволь интерпретировать HLT как следует и компилировать так же.
это верно только для тупых интерпретаторов, которые выполняют по одной команде за один свой цикл.
Это верно всегда.
это тоже неверно. Например bash откажется выполнять цикл, в котором нет done. Даже не начнёт. Что доказывает тот факт, что bash сначала транслирует цикл, а уже потом его выполняет. Как и компилятор.
Это тоже верно, кроме одного слова «один», тут имелся в виду мой конкретный пример (у него один проход, вообще — не обязательно).
И ты опять люто путаешь (про bash), смотри ниже вопрос.
я только про них и говорю, а не про какие-то лютые абстракции, как ты.
Тогда давай вопрос тебе:
У реализаций .NET, JVM и любых современных (продвинутых!) интерпретаторов обычно есть две трансляции и две интерпретации, то есть четыре _разных_ вещи, назови их.
Сегодняшние реальные™ компиляторы сначала транслируют код, а потом его уже исполняют.
Компиляторы типа GCC транслируют код, ничего они потом его не выполняют.
А не «по одной команде», как ты почему-то считаешь
С чего ты взял вообще что я как-то «считаю»? Я привожу простейший пример и про него говорю (потому что ты даже тут не понимаешь). Тут нечего считать. И это
что, попроще никак не придумать?
Чуть посложней пример, но ты не доволен. Что конкретно не понятно? Интерпретатор типизированного лямбда-исчисления с числами и арифметикой написанный на языке в котором есть функции, может даже на C++ можно один в один переписать. И как его расширить до компилятора с аллокацией регистров и оптимизациями выражений?
(видимо древних книжек начитался)
Я дал три ссылки на книги про компиляторы — почему они древние и какие нужно читать вместо, в студию.
Исходная версия quasimoto, :
Когда транслятор зацикливается
Трансляторы не зацикливаются. И да, в этих вопросах ты точно теоретик-кун :) Ну то есть ты даже не представляешь как циклы компилируются на уровне манипуляций которые компилятор производит — апостериори только смотришь на вход и выхлоп. Посмотри хотя бы http://llvm.org/docs/tutorial/LangImpl5.html#for-loop-expression.
Сегодня таких интерпретаторов не бывает. Сейчас интерпретатор как и компилятор обрабатывает _весь_ цикл, а уж потом его исполняет, когда полностью до конца распарсит.
Ты путаешь, но подожди — я тебе ниже вопрос задам.
транслятор ... Если это тупой интерпретатор
Книжек не читай @ свои определения придумывай :/
Т.е. компилятор сначала просматривает цикл, а потом его переводит в машкод, и его записывает на диск. Интерпретатор делает также, однако этот код никуда не пишет, а просто выполняет.
Ну, допустим, компилятор переводит — можно и даже нужно результат сохранять, так как это и есть назначение компилятора. Интерпретатор — нет, какое нафиг «код никуда не пишет», если у него нет никакого кода, только выполнение (а это его назначение интерпретатора).
это особенности реализации. Команда HLT вообще не имеет отношения к алгоритмам.
ЩИТО? L ::= (PLS | DBL | JMP Number | HLT)* — грамматика языка в вопросе, изволь интерпретировать HLT как следует и компилировать так же.
это верно только для тупых интерпретаторов, которые выполняют по одной команде за один свой цикл.
Это верно всегда.
это тоже неверно. Например bash откажется выполнять цикл, в котором нет done. Даже не начнёт. Что доказывает тот факт, что bash сначала транслирует цикл, а уже потом его выполняет. Как и компилятор.
Это тоже верно, кроме одного слова «один», тут имелся в виду мой конкретный пример (у него один проход, вообще — не обязательно).
И ты опять люто путаешь (про bash), смотри ниже вопрос.
я только про них и говорю, а не про какие-то лютые абстракции, как ты.
Тогда давай вопрос тебе:
У реализаций .NET, JVM и любых современных (продвинутых!) интерпретаторов обычно есть две трансляции и две интерпретации, то есть четыре _разных_ вещи, назови их.
Сегодняшние реальные™ компиляторы сначала транслируют код, а потом его уже исполняют.
Компиляторы типа GCC транслируют код, ничего они потом его не выполняют.
А не «по одной команде», как ты почему-то считаешь
С чего ты взял вообще что я как-то «считаю»? Я привожу простейший пример и про него говорю (потому что ты даже тут не понимаешь). Тут нечего считать. И это
что, попроще никак не придумать?
Чуть посложней пример, но ты не доволен. Что конкретно не понятно? Интерпретатор типизированного лямбда-исчисления с числами и арифметикой написанный на языке в котором есть функции, может даже на C++ можно один в один переписать. И как его расширить до компилятора с аллокацией регистров и оптимизациями выражений?
(видимо древних книжек начитался)
Я дал три ссылки на книги про компиляторы — почему они древние и какие нужно читать вместо, в студию.