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

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

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

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

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

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


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

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

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

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

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

Значит это то, что большинство интерпретаторов весят мегабайты и рассчитаны на большие машины.
Для того чтобы уложить их в однокристалку надо их серьезно урезать и подменять вызовы операционки чем-то своим. В частности для Lua есть такая документация. http://www.lua.org/notes/, но хотелось бы чего-нибудь более абстракного. Понимания всей идеологии.


Который стоит на 10/11-м месте по популярности. Меня во всяком случае весьма заинтересовал.
Есть еще древнейший tcl, чуть ли не ровесник Юникса.



Perl ориентирован прежде всего на разбор текста. Да и весьма тяжел.


Попробую объяснится. В принципе языки такого класса предназначены для написания несложных программ в сжатые сроки.
Да они медленные, но не требуют перекомпиляции. Да код открыт, но это несущественно если пишется для себя. Типизация на лету и несложные конструкции сильно облегчают жизнь людям не слишком искушенным в программировании, хотя станут головной болью в большм проекте.
Задача состоит в том, чтобы тонкое конфигурирование устройства было возложено на скрипт. Точно так же как в Квартусе встроен tcl, а сценарии игрушек написаны на Lua. Работа с железом возлагается на жестко прошитый софт, реакции на события отрабатывает скрипт.
Тогда можно буквально несколькими строчками из консоли перенастроить сложное устройство.

Это уже частности, но интересно заметить, что : "Perl ориентирован прежде всего на разбор текста" - это 1 из бытующих народных стереотипов, такая красивая народная легенда... Perl был первоначально ориентирован Лэрри Уолшем в 1986г. , да и то - что значит "ориентирован"? то что там заложен мощнейший механизм сопоставления с образцом, который, в принципе, был известен своей мощью задолго до Perl.
Но это было очень давно ... много времени утекло, чтобы убедится, что нынешний Perl это никак не средство ориентированное на обработку текстовой информации - возьмите глянуть книжку:
Водолазский В., Семериков В. "Энциклопедия Perl" - Спб.: Питер, 2002 - хорошие авторы, хорошая книжка - что ещё нужно ... которая, возможно, убедит вас в том, что как считают весьма многие, что Perl - это язык системного программирования в UNIX.

Кстати, python для платформы S60 есть здесь
http://www.forum.nokia.com/info/sw.nokia.c...on_for_S60.html
и здесь
http://opensource.nokia.com/projects/pythonfors60/

ARM архитектура. Может, пригодится ?

Глубоко не копал. Только установил его в 2005-м ( ещё одну из первых версий ) на свой N6600.
Поиграл камерой, записной книжкой и SMS-ками.
Проект активно развивается. И, по-моему, у них неплохо всё документировано.
Есть несколько интересных форумов по этой теме.
---

Форумчане, а, что скажете на счёт Prolog-а в контексте этого топика ?
Хороший язык. В начале 90-х очень я им увлёкался ...
Знаю людей, которые до сих пор его используют ( в собственных реализациях ).
Есть даже версии для Sinclair ZX Spectrum
http://spectrum128.spb.ru/help/MicroProlog.pdf

Не буду затевать священную войну, и за ссылки и за книжку большое спасибо, буду изучать.
Но затык в том, что и Перл и Питон штуки довольно громоздкие.
Я правда скачал исходники Питона 1.1, но все равно 2 с хвостом мегабайта в исходниках, т.е. резать и еще раз резать.
Очень хочеться знать где и как?
Что жизненно необходимо, а что можно и исключить?
Как представляются данные ?(для tcl немного разобрался)
Как работает интерпретатор?
Как определяются типы?
итд, итп.

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



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

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

Полноценный Форт "весит" примерно 8 кил. Полноценный - значит, полностью резидентный, самодостаточный, с компилятором, интерпретатором и зачаточной осью. Коммерческий Форт для однокристалок http://www.forth.com/embedded/index.html

Кросс-компилятор позволяет уменьшить вес резидентной части, т.е. интерпретатора, до примерно 2 кил (и это не предел). Фриверный - см., например, http://sourceforge.net/projects/c-fvm

Форт системы пишутся на разных языках есть, например, и на Bash:)

http://www.forthfreak.net/index.cgi?BashForth

BashForth is a ForthInterpreter, written entirely in the bash scripting language.
It requires bash v2.04 or higher. Its virtual machine makes use of StringThreadedCode.
Because its source code doesn't need to be compiled, it is highly portable (to any platform running bash).

P.S. Выводы делать Вам

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

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

Главное достоинство интерпретатора состоит в том, что он дает виртуальную машину, (почти ) не зависящую от железа.

Одними из первых до этого допедрили создатели Жабы. Однако с виртуальной машиной Жабы есть некоторые проблемы: полная машина довольно тяжеловесна (типично требует порядка 1М памяти и 32-бит проц). Прежде всего из-за выбранного ООП-подхода и встроенной сборки мусора. Если бы не это, виртуальная машина Жабы еще больше напоминала бы виртуальную машину Форта, т.к. обе суть стековые процессоры, но Форт-машина максимально простая, а Жаба-машина - с наворотами. Есть всевозможные варианты "урезанных Жаб", где прежде всего выбрасывают сборку мусора, но я в них не очень силен. В любом случае это будет кастрированный язык.

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

В основе .NET лежит примерно такая же виртуальная машина (интерпретатор), какая используется в Жаба-машине, т.е. стековый проц с ООП наворотами и сборкой мусора. Однако языков под эту машину наплодили тучу. В отличие от Жабы, мелкомягкие, похоже, не имеют намерений "урезать" .NET. Правда, есть умельцы, которые занялись этим самостоятельно (кому интересно - гуглите на слова .NET lego mindstorm).

Форт-машина - одна из самых простых и удобных виртуальных машин. Это тоже стековая машина, как Жаба-машина и .NET-машина, но максимально компактная и упрощенная. Идеально подходит для встроенных применений, но - увы - в отличие от .NET и Жаба-машин, не поддержана доступными высококачественными кросс-трансляторами с удобных ЯВУ. Есть полуоткрытый югославский проект, где они делают Форт-машину с С-кросс-компилятором, но это маргинальные штучки.

Все, что помимо этих трех машин (Жаба, НЕТ, Форт) упоминалось в треде - это все отстой и суксь, имхо. Уродцы, обреченные на вымирание, нечаянно появившиеся в ходе эволюционного процесса, имхо. Там есть достойные изумления экземпляры, такие как проект регистровой виртуальной машины, "Попугай" для Перла, если память не изменяет.

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


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

В списке 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"?

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

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

Существует 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


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

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

Если семантика языка программирования "Синяя птица", то я Шекспир
А чем тогда выступает синтаксис языка?

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

P.S. Что такое Ада у меня есть начальное представление.
Что мне, в свое время в ней понравилось, так несколько более выразительные конструкции
управляющих структур, чем в Си языке.
А не понравилось большой акцент на декларирование обрамляющих
описаний. ( Возможно в крупных проектах это позволяет контролировать их).

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


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

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


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


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

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

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

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


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

[quote name='Olej' date='Jan 30 2007, 13:22' post='203736']
...Да всё я прекрасно понял, только какая разница? происходит ли это "снаружи" или "извнутри" : когда всё это "все вместе становится исполняемой программой" то оно становится программой в шитом байт-коде для тсполняющей Forth виртуальной машины.
[/quote]
Поправка-
Современные Форт системы, обычно, транслируют исходный листинг в код целевого
процессора с той или иной степенью оптимизации

[quote name='Kopa' post='203525' date='Jan 30 2007, 08:16']
Из прведенных вариантов реализации Aды на Форте выбирается любой из предложенных.
[/quote]
Так в том-то и дело, что не выбирается никакое не только из приведенных, но и из подобно реализованных, птому как "оно" Ada - не является.
[/quote]

Не понятно,
Если сисстема пройдет регрессионные Aда тесты, то это еще не имеет права называться Aдой?
Прикладного программиста в последнюю очередь интересует внутренности реализации языка.

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

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

Одно из потверждений этому
Наработки этого проекта используются в Java машине с названием cacao ( cacaojvm.org )
Используемый GForth для портабельности написан на Cи.

http://www.complang.tuwien.ac.at/anton/vmgen/

Vmgen interpreter generator
Vmgen supports the construction of interpretive systems by generating the code for executing and dealing with virtual machine (VM) instructions from simple descriptions of the VM instructions.

Vmgen generates code for executing VM instructions (with optional tracing), for generating VM code, for disassembling VM code, and for profiling VM instruction sequences. A VM instruction description looks like this:

add ( i1 i2 -- i )
i = i1+i2;

Vmgen supports several techniques for writing efficient interpreters: virtual machine interpreters, threaded code, combining VM instructions into superinstructions, keeping the top-of-stack in a register, scheduling the dispatch of the next VM instruction, and a couple of minor optimizations. Interpreters created with vmgen usually are faster than competing interpreters and are typically only a factor of 2-10 slower than the code generateed by native-code compilers.

Vmgen has special support for stack-based VMs (but it can also be used to advantage when implementing a register-based VM).

Vmgen is currently distributed with Gforth (because it needs Gforth to run, and Gforth needs it to build), and is installed together with Gforth (read INSTALL for instructions).

P.S. Успехов.