Скриптовые языки, что почитать? Опции

[beer_warrior]

Сама по себе тема поднималась на форуме неоднократно, и сам я немало нафлудил в этих топиках.
Речь идет о портировании известных скриптовых языков на МК.
Есть немало открытых исходников и готовых портов.
Но в данном случае речь идет о теории. Где можно взять инфу по внутреннему устройству интерпретаторов?
Задача - научиться самому портировать язык, причем возможно с урезанием функциональности (т.е копанием во внутренностях), на любой кристалл и/или RTOS.
Копание вслепую не слишком результативно

[?ELF]

Сама по себе тема поднималась на форуме неоднократно, и сам я немало нафлудил в этих топиках.
Речь идет о портировании известных скриптовых языков на МК.
Есть немало открытых исходников и готовых портов.
Но в данном случае речь идет о теории. Где можно взять инфу по внутреннему устройству интерпретаторов?
Задача - научиться самому портировать язык, причем возможно с урезанием функциональности (т.е копанием во внутренностях), на любой кристалл и/или RTOS.
Копание вслепую не слишком результативно

IMHO: PHP неплохо документирован и источников информации по нему много.
А последние версии, по возможностям, не уступают Perl-у ( при использовании в консольных приложениях ).

Ещё, вроде бы, существует порт Lisp-а для МК. Но, «в свободной продаже» не встречал его.
( могу ошибаться. Лет 15 уже с ним работать не доводилось ).

Ёклмн... ещё одна поправка.
Есть же ветка Forth, начатая когда-то, Андреем Черезовым ( SP-Forth, http://www.eserv.ru/eserv/, http://www.enet.ru/win/cherezov/ ), поддержанная Николаем Немцевым ( автор nncron & nnbackup ― http://www.nncron.ru/).
Вот уж что годится для портирования на МК, так это Forth !

Кстати, в соседней ветке, уважаемый Kopa, запостил линк на девайсы, работающие под управлением редкостной Forth-OS
http://technoforth.ru/index.php?page=mPOS64

Сообщение отредактировал ?ELF - Jan 27 2007, 01:15

[Olej]

Ещё, вроде бы, существует порт Lisp-а для МК. Но, «в свободной продаже» не встречал его.
( могу ошибаться. Лет 15 уже с ним работать не доводилось ).

Ёклмн... ещё одна поправка.
Есть же ветка Forth, начатая когда-то, Андреем Черезовым ( SP-Forth, http://www.eserv.ru/eserv/, http://www.enet.ru/win/cherezov/ ), поддержанная Николаем Немцевым ( автор nncron & nnbackup ― http://www.nncron.ru/).
Вот уж что годится для портирования на МК, так это Forth !

Кстати, в соседней ветке, уважаемый Kopa, запостил линк на девайсы, работающие под управлением редкостной Forth-OS
http://technoforth.ru/index.php?page=mPOS64

И Forth и LISP - портируемы и реализуемы в малых конфигурациях (сам помню раскручивал Forth ещё для x8086) ... но это всё - "другая песня" - это стековые машины, с которыми должны быть интегрированы приложения-программы, т.е. то, что называется: одноязыковая среда. К скриптовым языкам - управления заданиями - это имеет очень опосредованное отношение.
По моему мнению (прогнозу, предположению - IMHO) единственное, что перспективно портировать в этом смысле - это Perl; благо, всё что к нему относится - это free + open source.

[Kopa]

И Forth и LISP - портируемы и реализуемы в малых конфигурациях (сам помню раскручивал Forth ещё для x8086) ... но это всё - "другая песня" - это стековые машины, с которыми должны быть интегрированы приложения-программы, т.е. то, что называется: одноязыковая среда.
К скриптовым языкам - управления заданиями - это имеет очень опосредованное отношение.

"Скриптовость" языков и подразумевает интегрирование скрипта с базисным языком без
процедуры перекомпилирования базиса

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

[Olej]

"Скриптовость" языков и подразумевает интегрирование скрипта с базисным языком без
процедуры перекомпилирования базиса

Круто ... зауважал ... чем-то напомнило забытый "Общий курс политэкономии"
Скриптовость языка, вообще то говоря, ничего не подразумевает - чем же интегрирован shell (разные sell: ksh, bash etc.) с базовым языком С ОС UNIX?

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

Можно расширить... Но только в "одноязыковых" системах, см. на этот счёт проекты школы Н.Вирта: Modula - Lylith - Oberon - BlyeBottle ...
Если ваши приложения - в Forth системе, то Forth может быть и языком управления задачами, если ваши приложения - Lisp, то и стековой машиной Lisp вы можете управлять из Lisp... Но управлять выполнением из скриптового языка заданиями, приведенными в ELF-формат из C, C++, FORTRAN, Ada, Forth & Lisp (да ещё и одновременно из разных) - ни из Forth ни из Lisp вы не построите управляющую надстройку.

В этом смысле путаницу вносит неточно сформулированное исходное пожелание:

Речь идет о портировании известных скриптовых языков на МК.
...
- научиться самому портировать язык, причем возможно с урезанием функциональности (т.е копанием во внутренностях), на любой кристалл и/или RTOS.

- что сие значит?

А в отношении:

Ну почему же, есть готовая реализация tcl для ARM, Lua для М16.Компилил Lua для ARM, немножко игрался. Но чтобы сделать полноценную реализацию надо очень хорошо знать внутренности (представление данных, механизм исполнения итп.). К сожалению без полноценного знания теории копание исходников сродни забиванию шурупов молотком Поэтому и спрашиваю.
Возможно при вдумчивой оценке и Perl окажется решением.
А может Python удастся урезать.

... есть. А ещё есть Ruby и много другого .... но всё это экзотика последних времён, в которой всё очень зыбко и меняется, и если переносить/портировать, и тратить на это много времени - то то, в первую очередь: а). для чего есть уже устоявшиеся стандарты синтаксиса и семантики + б). для чего есть уже большие объёмы готового наработанного кода. Именно только из таких соображений я предложил Perl. и это только моё IMHO.

[Kopa]

Форт можно расширить до синтаксиса и семантики заданного языка, что часто и делают,

Можно расширить... Но только в "одноязыковых" системах, см. на этот счёт проекты школы Н.Вирта: Modula - Lylith - Oberon - BlyeBottle ...
Если ваши приложения - в Forth системе, то Forth может быть и языком управления задачами,

"Одноязыковость" в вашем контексте подразумевает следование синтаксису и семантики
заданного языка?
Но Форт может менять свой синтаксис и семантику, без перекомпиляции ядра, до произвольно заданного языка!!!. Форт при этом тоже остается доступным.

... если ваши приложения - Lisp, то и стековой машиной Lisp вы можете управлять из Lisp... Но управлять выполнением из скриптового языка заданиями, приведенными в ELF-формат из C, C++, FORTRAN, Ada, Forth & Lisp (да ещё и одновременно из разных) - ни из Forth ни из Lisp вы не построите управляющую надстройку.

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

P.S. Под базисом языка имелось ввиду его синтаксис и семантика. ( shell не С, С++ язык)

Сообщение отредактировал Kopa - Jan 29 2007, 07:04

[Olej]

"Одноязыковость" в вашем контексте подразумевает следование синтаксису и семантики
заданного языка?

"Одноязыковость" в моём контексте ( - собственно, это не мой контекст: я его "украл" у Н.Вирта) подразумевает следование всей системы семантике и понятиям выбранного языка реализации. Лучшия тому пример: OS BlueBottle, реализованной в рамках понятий языка Oberon (или Zennon), которые (понятия) просто невозможно реализовать/смоделировать в рамках понятий другого языка реализации, например С; пример таким понятиям: "активные объекты" и мониторы Хоара.

Но Форт может менять свой синтаксис и семантику, без перекомпиляции ядра, до произвольно заданного языка!!!. Форт при этом тоже остается доступным.

Ну-ка, ну-ка - "реализуйте" мне в Forth семантику Ada (с пакетами, пространствами видимости, параллельностями и рандеву ... etc.).
- Я духов вызывать могу из бездны!
- Я тоже могу. Весь вопрос в том - явятся ли они на зов?
(с) В.Шекспир "Генрих IV".
И, собственно, что вы собираетесь конкретно реализовывать ... ("семантика" сама по себе ведь это некоторая фикция, в роде Синей Птицы?) :
- компилятор с Ada написанный на Forth?
- исполняющую систему, выполненную на Forth, интерпретирующую код на Ada?
- ... или ещё чего ?
(это, конечно, при условии, что вы отчётливо разграничиваете: а). компилятор б). интерпретатор в). моделирующую виртуальную машину, реализующую исполняющую систему, ... ).

[=AK=]

Ну-ка, ну-ка - "реализуйте" мне в Forth семантику Ada (с пакетами, пространствами видимости, параллельностями и рандеву ... etc.).
- Я духов вызывать могу из бездны!
- Я тоже могу. Весь вопрос в том - явятся ли они на зов?
(с) В.Шекспир "Генрих IV".
И, собственно, что вы собираетесь конкретно реализовывать ... ("семантика" сама по себе ведь это некоторая фикция, в роде Синей Птицы?) :
- компилятор с Ada написанный на Forth?
- исполняющую систему, выполненную на Forth, интерпретирующую код на Ada?
- ... или ещё чего ?
(это, конечно, при условии, что вы отчётливо разграничиваете: а). компилятор б). интерпретатор в). моделирующую виртуальную машину, реализующую исполняющую систему, ... ).

В списке http://www.idiom.com/free-compilers/ECATEG...compiler-1.html найдите "компилятор компиляторов" Gray Антона Эртла. Скачайте и, используя рекомендованный (его же) Форт, задайте ему БНФ Ады, как описано в описании, и запустите. Вы получите компилятор Ады, исполняемый Форт-системой. А также интерпретатор и виртуальную машину (стековую, ессно) в том же флаконе. Таков Форт

[Olej]

В списке http://www.idiom.com/free-compilers/ECATEG...compiler-1.html найдите "компилятор компиляторов" Gray Антона Эртла. Скачайте и, используя рекомендованный (его же) Форт, задайте ему БНФ Ады, как описано в описании, и запустите. Вы получите компилятор Ады, исполняемый Форт-системой. А также интерпретатор и виртуальную машину (стековую, ессно) в том же флаконе. Таков Форт

Не сомневаюсь, и достаточно хорошо представляю как это делается ... да только:
1. Вы считаете, что откомпилировать в некоторый промежуточный байт-код текст с Ada + затем этот промежуточный код исполнять на стековой виртуальной машине - это и есть Ada, и соответствует целям и задачам, для которых на неё потратили столько времени? Так вы это скажите тем, кто делал эту разработаку и её продолжает, или, неплохо, тем, кто финансировал эту программу, и ...
2. В сообществе Ada (это как 1 частный пример) есть такой порядок признания "того что является Ada":
- есть система из нескольких сот регрессивных тестов ... которая в некоторых системах может выполняться по пара-десятка часов...
- система тестов сертифицирована и не подлежит изменениям;
- та представленная Ada-система, которая проходит все тесты - считается Ada-системой, всё остальное считается ... "неизвестно что" ...
- в мире существует 5 систем - прошедшие систему сертификации (до какого-то времени в прошлом ) - среди них, не только среди прошедших, но просто среди представляемых - нет ни 1-й, реализованной по описанной вами схеме a'la Java...
Ну и что вы таким способом получите? "система в кое-чём напоминающую Ada"?

[=AK=]

Не сомневаюсь, и достаточно хорошо представляю как это делается ... да только:
...
Ну и что вы таким способом получите? "система в кое-чём напоминающую Ada"?

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

[Olej]

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

Это не реализация, это - игрушка.
На такое не будет ни заказчика, ни финансирования - никогда.

[=AK=]

Это не реализация, это - игрушка.
На такое не будет ни заказчика, ни финансирования - никогда.

Существует A# - a port of Ada to the Microsoft .NET Platform: "A# is freely distributed by the Department of Computer Science at the United States Air Force Academy as a service to the Ada community under the terms of the GNU general public license." Hа мой непросвещенный взгляд выглядит как достаточно серьезный проект, вполне пригодный для изучения как языка Ada, так и .NET

1. Вы считаете, что откомпилировать в некоторый промежуточный байт-код текст с Ada + затем этот промежуточный код исполнять на стековой виртуальной машине - это и есть Ada, и соответствует целям и задачам, для которых на неё потратили столько времени? Так вы это скажите тем, кто делал эту разработаку и её продолжает, или, неплохо, тем, кто финансировал эту программу, и ...

Я не специалист в Аде. Задайте свои вопросы разработчикам A#, на приведенной ссылке есть адрес е-мэйл.

Кстати, Вы не поняли, как будет работать система на основе Форт+Gray. Там нет промежуточного байт-кода, раздельных компилятора и интерпретатора. Так, как Вы описали, работает A#. А в Форт+Gray, после загрузки БНФ языка (в нашем примере - Ада), грузится исходник программы на этом языке, после чего все вместе становится исполняемой программой. Совсем другая концепция, как видите.

[Olej]

Кстати, Вы не поняли, как будет работать система на основе Форт+Gray. Там нет промежуточного байт-кода, раздельных компилятора и интерпретатора. Так, как Вы описали, работает A#. А в Форт+Gray, после загрузки БНФ языка (в нашем примере - Ада), грузится исходник программы на этом языке, после чего все вместе становится исполняемой программой. Совсем другая концепция, как видите.

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

Я не специалист в Аде. Задайте свои вопросы разработчикам A#, на приведенной ссылке есть адрес е-мэйл.

Ada - это только пример, так, к слову.
Та же история будет и с С/С++ : смоделировать синтаксически/семантически его можно, и разными средствами и разными tools, но очень многие веши в С/С++ окужении обеспечиваются (обеспечивают связь с) операционным окружением - где-то это ОС, где-то виртуальная Forth-машина, кому-то нравится p-код, через который так любили реализовывать Pascal. И без "средств под рукой" которые обеспечивает операционная среда С++ (большая часть которых вообще не являются частью языка, а предоставляются стандартными библиатеками) моделируемый на виртуальной машине представляет только "академический" интерес...
Чтоб было понятнее, о каких "вкусностях" речь, я назову только некоторые из них "на-вскидку", первое что в голову пришло: setjmp()/longjmp(), сигналы POSIX + сигналы реального врмени + ... sigsetjmp()/siglongjmp(), fork(), pthread_*() ... и мн. мн. других. Если ваша операционная среда не оперирует такими сущностями - то она и не может их предоставлять в С++, а кому тогда нужен такой С++, кроме отдельного узкого круга применений?

Вот такой "разночитаемостью" эта тема обязана размытой формулировке вопроса:

Речь идет о портировании известных скриптовых языков на МК.

- если этот МК - это голая железка, которую нужно/можно оснастить операционной средой, которая в этом случае может быть и той же стековой Forth-машиной - то "портирование скриптовых языков" имеет один смысл...
- а если этот МК предполагает, что он оснащён своей операционной средой - то совершенно другой, причём тоже радикально отличающиеся: RTOS QNX - это будет совершенно одно решение, а BlueBottle "стояший" на семантике Oberon/Zennon - то совершенно другое;
- а если: "на все случаи жизни" - то вообще не будет никакого решения.

Из прведенных вариантов реализации Aды на Форте выбирается любой из предложенных.

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

[=AK=]

когда всё это "все вместе становится исполняемой программой" то оно становится программой в шитом байт-коде для тсполняющей Forth виртуальной машины.

Не припомню, чтобы кто-то употреблял словосочетание "шитый байт-код". По раздельности - да, это общеупотребительные термины.

Скомпилированный Жаба-код принято называть байт-кодом, код для CLR, если не ошибаюсь, тоже иногда так называют. Я бы сказал, что байт-кодом называют бинарный код для любой виртуальной машины. Байт-код как правило используют при раздельных этапах компиляции и интерпретации, т.е. при кросс-компиляции. При этом компилятор держит в своей памяти все необходимые таблицы и ссылки, и нет никакой нужды встраивать часть этой информации в скомпилированный код.

Скомпилированный Фортом внутренний код обычно называют шитым кодом, отличая прямой шитый код, косвенный шитый код, и др. В отличие от байт-кода, Фортовский шитый код содержит дополнительную информацию, в частности - ссылки на поля определений "назад" (так наз. "поля связи"), необходимые для поиска в словаре. Из-за этого, имхо, его и называют "шитым", поскольку эти ссылки "сшивают" код в словарь. A кратность байту для шитого кода не обязательна, поскольку во времена ранних Фортов еще в ходу были машины с некратной байту разрядностью. Шитый код используют в "самодостаточных" системах, где нет разделения между компиляцией и интерпретацией.

Да и разговор то об другом затевался?

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