Здравствуйте, Holden Claulfield, Вы писали:
V>>Для одного из проектов с использованием GSM/GPS трекеров, пришлось разработать виртуальную машину V>>для исполнения скриптов на самих устройствах.
HC>Не смотрели тут?
Здравствуйте, voidlizard, Вы писали:
V>Просто у меня сейчас затык, как организовать локальные переменные, имея 128 байт стека (ну в крайнем случае стек можно расширить за счет хипа, конечно), V>не имея произвольного доступа к индексным регистрам стека, а форт-машина, понятное дело перестанет ей быть, если даст возможность коду рулить V>указателями стека. Доступ к хипу достаточно дорогой, то есть устраивать "софтварный" (реализованный на самом форте) стек для локальных переменных V>очень не хочется (хотя и можно)
Первое — последний раз, когда я смотрел на Форт, там были слова для прямого доступа к стеку по смещению от вершины.
Второе — я не копенгаген в компиляторах, потому мой совет, скорее всего, окажется непрактичным, но все же выскажусь:
а) чисто-функциональные программы тривиально компилируются в код для стековой машины (аргументы функций запихиваются в стек, функция их съедает и оставляет на вершине стека результат). Под функциональной чистотой в данном случае понимается только отсутствие мутабельных локальных переменных, глобальные переменные в куче, ввод-вывод и т.д. не запрещены.
б) SSA-преобразование превращает любую процедуру в чисто-функциональную.
V>Для одного из проектов с использованием GSM/GPS трекеров, пришлось разработать виртуальную машину V>для исполнения скриптов на самих устройствах.
V>Сами трекеры построены на базе Microchip PIC18 — если кто не знает — около 3Kb RAM, 40 Kb Program Flash ну и в нашем V>случае есть еще дополнительно 32Kb EEPROM, куда и пишутся байткоды скриптов, тк больше некуда — при питании от батарейки V>устройство не сможет, например, само себе прошить program flash. Исходя из ограниченных ресурсов, ASM в качестве языка
...
Рекомендую списаться с этим челом из Австралии: http://www.rtjcom.com/main.php?p=home
К его машинке simpleRTJ есть очень пользительный debugger и вообще.
V>Для одного из проектов с использованием GSM/GPS трекеров, пришлось разработать виртуальную машину V>для исполнения скриптов на самих устройствах. V>Мнения? V>--- V>dmz
а вы берете во внимание, что любой интерпертируемый язык на таком батарейном устройстве, будет грубо говоря на операцию тратить кулонов(мера измерения заряда), на порядок-полтора боьше на нативном коде? аккумуляторы будут садиться со страшною силой?
есть сомнения в практической пригодости продукта или расширяемости спектра задач на нем.
я бы по любому уходил от виртмашины в данном случае.
Для одного из проектов с использованием GSM/GPS трекеров, пришлось разработать виртуальную машину
для исполнения скриптов на самих устройствах.
Сами трекеры построены на базе Microchip PIC18 — если кто не знает — около 3Kb RAM, 40 Kb Program Flash ну и в нашем
случае есть еще дополнительно 32Kb EEPROM, куда и пишутся байткоды скриптов, тк больше некуда — при питании от батарейки
устройство не сможет, например, само себе прошить program flash. Исходя из ограниченных ресурсов, ASM в качестве языка
разработки прошивки, отсутствия внятной документации по теме — было принято решение разработать Fort-машину, которая бы
исполняла на байткод, скомпилированный вовне и залитый в EEPROM, что и было сделано. Операции и переменные — в основном
8-битные, адреса — от 8 до 24 бит, но в принципе можно поднатужиться и реализовать 16-разрядную арифметику (это все специфика PIC-а).
Forth, при всех своих достоинствах, язык несколько жутковатый, к тому же его подход заставляет решать множество проблем,
которые в нормальной жизни обычно не возникают. Грубо говоря, бывают языки, которые стремятся сократить побочные эффекты,
а бывают языки, которые строятся из побочных эффектов (это про форт). Соответственно, в следующем поколении устройств
хочется переехать с форта на что нибудь еще.
Вопрос, собственно, вот в чем:
0) Есть ли какие-то языки, которые можно успешно компилировать в байткоды для форт-машины ( двухстековая машина, произвольного доступа к
элементам стека — нет, доступ к памяти есть, но дороговато обходится) ?
1) Есть ли какие-то хорошо специфицированные, несложные (в принципе любая несложная, если в ней не более сотни инструкций) виртуальные машины,
с компактными опкодами? Желательно, что бы были готовые компиляторы, которые генерировали для них код. LUA5, Python — некомпактны, Java — хороша,
но писать компилятор и VM сложно (много инструкций, разрядность и тп) ?
2) Может быть есть хотя бы какие-то заготовки, в виде парсера языка в AST, или просто язык с компактной VM которую несложно портировать.
То есть, что хотелось бы иметь в идеале: язык, компилятор с него в байткоды (компактность не хуже форта) и четкая спецификация виртуальной машины, которую надо реализовать, что бы эти байткоды исполнять. Управление памятью должно быть за счет компилятора (что вполне возможно, кмк)
В качестве программы-минимума, хотя бы какой-нибудь неплохой язык и парсер его в AST, но отдельно стоящий, т.е. что бы не приходилось выдирать его из LUA,
а можно было просто взять и использовать, в этом случае хорошо бы что бы язык и компилятор были реализованы на каком-нибудь человеческом языке, а не С/С++/Java,
тк придется дописывать трансляцию в байткоды, и нет столько времени, что бы ковыряться с чужим кодом на вышеозначенных языках.
Бэкграунд: смотрел PyPy, за отведенное время не осилил (вероятно, к нему еще вернусь, тк выглядит как почти то, что надо, но непонятно как это использовать).
Смотрел LLVM, не портируемо (куда нам надо). Смотрел Parrot, сложно и не портируемо.
Мнения?
---
dmz
если модераторы восстановят пароль от моего старого аккаунта, я буду совсем не против
Здравствуйте, voidlizard, Вы писали:
V>0) Есть ли какие-то языки, которые можно успешно компилировать в байткоды для форт-машины ( двухстековая машина, произвольного доступа к V>элементам стека — нет, доступ к памяти есть, но дороговато обходится) ?
Scheme?
V>1) Есть ли какие-то хорошо специфицированные, несложные (в принципе любая несложная, если в ней не более сотни инструкций) виртуальные машины, V>с компактными опкодами? Желательно, что бы были готовые компиляторы, которые генерировали для них код. LUA5, Python — некомпактны, Java — хороша, V>но писать компилятор и VM сложно (много инструкций, разрядность и тп) ?
JVM можно не всю реализовывать. Посмотри на http://en.wikipedia.org/wiki/Java_Card — оно очень близко.
V>>0) Есть ли какие-то языки, которые можно успешно компилировать в байткоды для форт-машины ( двухстековая машина, произвольного доступа к V>>элементам стека — нет, доступ к памяти есть, но дороговато обходится) ?
C>Scheme?
Хотелось бы для начала увидеть компиляцию Scheme во что-нибудь вообще. Честно говоря, не слишком представляю как устроен лисп — он
точно нормально ляжет на двухстековую машину? Или придется писать какой-то менеджер хипа для работы со списками, а стек данных
будет просто простаивать?
V>>1) Есть ли какие-то хорошо специфицированные, несложные (в принципе любая несложная, если в ней не более сотни инструкций) виртуальные машины, V>>с компактными опкодами? Желательно, что бы были готовые компиляторы, которые генерировали для них код. LUA5, Python — некомпактны, Java — хороша, V>>но писать компилятор и VM сложно (много инструкций, разрядность и тп) ?
C>JVM можно не всю реализовывать. Посмотри на http://en.wikipedia.org/wiki/Java_Card — оно очень близко.
Вроде смотрел, посмотрю еще раз. Если JVM реализовать не всю, но как быть с консистентностью компилятора и VM? Как ее хотя бы проверять при компиляции?
Свой компилятор писать не хочется, а если уж его писать, то уж не джаву точно.
Здравствуйте, voidlizard, Вы писали:
C>>Scheme? V>Хотелось бы для начала увидеть компиляцию Scheme во что-нибудь вообще. Честно говоря, не слишком представляю как устроен лисп — он V>точно нормально ляжет на двухстековую машину? Или придется писать какой-то менеджер хипа для работы со списками, а стек данных V>будет просто простаивать?
У NASA это вроде получалось
C>>JVM можно не всю реализовывать. Посмотри на http://en.wikipedia.org/wiki/Java_Card — оно очень близко. V>Вроде смотрел, посмотрю еще раз. Если JVM реализовать не всю, но как быть с консистентностью компилятора и VM? Как ее хотя бы проверять при компиляции?
Есть верификаторы того, что в байт-коде ничего левого не будет.
V>Свой компилятор писать не хочется, а если уж его писать, то уж не джаву точно.
Компилятор используется стандартный, просто нужно определённых конструкций избегать будет.
C>>>Scheme? V>>Хотелось бы для начала увидеть компиляцию Scheme во что-нибудь вообще. Честно говоря, не слишком представляю как устроен лисп — он V>>точно нормально ляжет на двухстековую машину? Или придется писать какой-то менеджер хипа для работы со списками, а стек данных V>>будет просто простаивать? C>У NASA это вроде получалось
Что именно? Где посмотреть? Просто если они на форт-подобную машину спортировали Scheme, то может какое-то подобие руби-питона-луа туда тоже
спортируется, а для скриптинга оно более человечное, нежели лисп-подобие...
Просто у меня сейчас затык, как организовать локальные переменные, имея 128 байт стека (ну в крайнем случае стек можно расширить за счет хипа, конечно),
не имея произвольного доступа к индексным регистрам стека, а форт-машина, понятное дело перестанет ей быть, если даст возможность коду рулить
указателями стека. Доступ к хипу достаточно дорогой, то есть устраивать "софтварный" (реализованный на самом форте) стек для локальных переменных
очень не хочется (хотя и можно)
C>>>JVM можно не всю реализовывать. Посмотри на http://en.wikipedia.org/wiki/Java_Card — оно очень близко. V>>Вроде смотрел, посмотрю еще раз. Если JVM реализовать не всю, но как быть с консистентностью компилятора и VM? Как ее хотя бы проверять при компиляции? C>Есть верификаторы того, что в байт-коде ничего левого не будет.
V>>Свой компилятор писать не хочется, а если уж его писать, то уж не джаву точно. C>Компилятор используется стандартный, просто нужно определённых конструкций избегать будет.
Звучит не очень прикольно, и, насколько я понимаю, JavaCard — не опенсорц, то есть подкрутить компайлер если что — нельзя?
V>Forth, при всех своих достоинствах, язык несколько жутковатый, к тому же его подход заставляет решать множество проблем, V>которые в нормальной жизни обычно не возникают. Грубо говоря, бывают языки, которые стремятся сократить побочные эффекты, V>а бывают языки, которые строятся из побочных эффектов (это про форт). Соответственно, в следующем поколении устройств V>хочется переехать с форта на что нибудь еще.
Может проще поднатужится и нормально разобратся с фортом?
То есть сделать нормальный DSL на форте и использовать только его для прикладного кодирования.
V>То есть, что хотелось бы иметь в идеале: язык, компилятор с него в байткоды (компактность не хуже форта) и четкая спецификация виртуальной машины, которую надо реализовать, что бы эти байткоды исполнять. Управление памятью должно быть за счет компилятора (что вполне возможно, кмк)
У Ocaml'а достаточно несложный и компактный байт код, но боюсь у вас жестковаты ограничения. http://pauillac.inria.fr/~lebotlan/docaml_html/english/index.html
V>В качестве программы-минимума, хотя бы какой-нибудь неплохой язык и парсер его в AST, но отдельно стоящий, т.е. что бы не приходилось выдирать его из LUA,
Здравствуйте, voidlizard, Вы писали:
V>Исходя из ограниченных ресурсов, ASM в качестве языка V>разработки прошивки, отсутствия внятной документации по теме — было принято решение разработать Fort-машину, которая бы исполняла на байткод, скомпилированный вовне и залитый в EEPROM, что и было сделано.
Поправьте меня если я ошибаюсь -- вместо того, чтобы написать нормальный компилятор C для вашей архитектуры, вы, при таких-то ограничениях, разрабатываете какие-то VM? А если не секрет -- зачем?
T>Поправьте меня если я ошибаюсь -- вместо того, чтобы написать нормальный компилятор C для вашей архитектуры, вы, при таких-то ограничениях, разрабатываете какие-то VM? А если не секрет -- зачем?
Что бы дистанционно заливать скрипты в устройства, причем скрипты должны быть managed — те косяки в скриптах не должны вешать устройство — если оно
вдруг заткнулось из-за скрипта, то должна быть возможность дистанционно-же вывести его из ступора и перезалить скрипт — т.е. прошивка работает как супервайзер,
типичный kernel mode (а скрипт — user mode). И кстати, отлично все работает — т.е скорость работы устройства пока ограничивается скоростью коммуникаций, а не
скоростью исполнения скрипта.
А компиляторы C под PIC18 есть, правда довольно отстойные (но не думаю, что я написал бы лучше, особенно за те две полторы недели, которые ушли на разработку
VM на пике и транслятора форта и эмулятора на PC)
FR>Может проще поднатужится и нормально разобратся с фортом?
Да куда уж нормальнее, даром что сам его написал.
FR>То есть сделать нормальный DSL на форте и использовать только его для прикладного кодирования.
Фактически — так оно сейчас и есть; но хотелось бы большего (в будущем).
Тут фишка в том, что ядро прошивки пришлось сделать на ASM по разного рода соображениям, и соответственно у
нас будет очень плохо с его поддержкой; пока не переедем на другую платформу и не перепишем ядро на C. В общем, чем меньше мы будем
лазить в ядро — тем будет лучше, кроме того, на асме очень уныло делать разные прикладные вещи (которые можно было бы биндить потом в форт) —
например, парсинг строк. На форте и то веселее, затраты времени не сравнимы.
FR>Тут http://www.cminusminus.org/code.html#luaml есть старенькая версия lua, с ast и раздельной компиляцией.
FR>Из скриптов еще есть более компактный чем lua Squirrel http://squirrel-lang.org/default.aspx
Здравствуйте, voidlizard, Вы писали:
T>>Поправьте меня если я ошибаюсь -- вместо того, чтобы написать нормальный компилятор C для вашей архитектуры, вы, при таких-то ограничениях, разрабатываете какие-то VM? А если не секрет -- зачем?
V>Что бы дистанционно заливать скрипты в устройства, причем скрипты должны быть managed — те косяки в скриптах не должны вешать устройство — если оно V>вдруг заткнулось из-за скрипта, то должна быть возможность дистанционно-же вывести его из ступора и перезалить скрипт — т.е. прошивка работает как супервайзер,
мы подобную задачу решали насколько я помню ватчодогом и перезапуском заливки. то есть если программа застряла ватчдог запускает загрузчик, тот плюет в канал запрос на перезагрузку, и смотрит идут ли байты в ответ. если идут — читает их в пямять и пускает снова. осталось только придумать, как у вас обеспечить работу ватчдога.
Здравствуйте, merk, Вы писали:
M>мы подобную задачу решали насколько я помню ватчодогом и перезапуском заливки. то есть если программа застряла ватчдог запускает загрузчик, тот плюет в канал запрос на перезагрузку, и смотрит идут ли байты в ответ. если идут — читает их в пямять и пускает снова. осталось только придумать, как у вас обеспечить работу ватчдога.
гм. когда прочел подробней первый пост..увидел, что устройство принципиально не может само себя прошить.
это плохо. могло б прошить — проблем бы не было.
M>а вы берете во внимание, что любой интерпертируемый язык на таком батарейном устройстве, будет грубо говоря на операцию тратить кулонов(мера измерения заряда), на M>порядок-полтора боьше на нативном коде? аккумуляторы будут садиться со страшною силой?
Пик потребляет минимум на порядок на порядок меньше, чем GSM и GPS модули. Кроме того, предшественник данного устройства, сделанный бестолковыми швейцарско-бельгийско-венгерско-китайскими разработчиками вообще не знал команды sleep и молотил все время — а раз так, то какая разница, какие именно команды ему молотить? В общем, думаю, вы ошибаетесь в данном вопросе.
M>есть сомнения в практической пригодости продукта или расширяемости спектра задач на нем. M>я бы по любому уходил от виртмашины в данном случае.
Сомнения, безусловно, ваше право — но лично я считаю, что на самом деле все обстоит с точностью до наоборот, т.е. пока мы не
разработали данную прошивку на это устройство, оно было непригодным ни для каких практических применений, в т.ч.
и по соображениям расхода энергии, теперь же у нас есть возможность тонко настраивать режимы работы, добиваясь наименьшего
потребления энергии для данного конкретного режима эксплуатации. В общем-то, тему практичности предлагаю не развивать — вы не знаете
нашей ситуации в любом случае, так что спор все равно будет ни о чем.
M>>мы подобную задачу решали насколько я помню ватчодогом и перезапуском заливки. то есть если программа застряла ватчдог запускает загрузчик, тот плюет в канал запрос на перезагрузку, и смотрит идут ли байты в ответ. если идут — читает их в пямять и пускает снова. осталось только придумать, как у вас обеспечить работу ватчдога.
M>гм. когда прочел подробней первый пост..увидел, что устройство принципиально не может само себя прошить. M>это плохо. могло б прошить — проблем бы не было.
Проблема бы была, так как это очень опасно для функционирования устройства. В текущем виде скрипт ни при каком раскладе
не может прострелить голову прошивке своей работой, т.к. сидит в песочнице и имеет доступ только к тем функциям, которые ему предоставила
прошивка. А скрипты планируется заливать пользовательские.
dmz>Проблема бы была, так как это очень опасно для функционирования устройства. В текущем виде скрипт ни при каком раскладе dmz>не может прострелить голову прошивке своей работой, т.к. сидит в песочнице и имеет доступ только к тем функциям, которые ему предоставила dmz>прошивка. А скрипты планируется заливать пользовательские.
ну если таки нужна VM для микроконтроллера, нужно гуглить
virtual machine microcontroller. http://www.scribd.com/doc/2784076/Virtual-Machines-Running-on-Microcontrollers
проц вроде правда avr, но там какой-то опен сорсе. в детали не вникал.
можно погуглить VM microcontroller, virtual machine PIC...
кстати интересно чем кончатся ваши поиски.
если не трудно, сообщите потом о результатах.
Здравствуйте, voidlizard, Вы писали:
V>1) Есть ли какие-то хорошо специфицированные, несложные (в принципе любая несложная, если в ней не более сотни инструкций) виртуальные машины, V>с компактными опкодами? Желательно, что бы были готовые компиляторы, которые генерировали для них код. LUA5, Python — некомпактны, Java — хороша, V>но писать компилятор и VM сложно (много инструкций, разрядность и тп) ?
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, Holden Claulfield, Вы писали:
V>>>Для одного из проектов с использованием GSM/GPS трекеров, пришлось разработать виртуальную машину V>>>для исполнения скриптов на самих устройствах.
HC>>Не смотрели тут?
M>На 40kb запускать? Оптимистично то как!
Откровенно говоря 32 и 40 кб (+ еще 3кб) — это колоссальный ресурс. Не думаю, что вы в него уложите стандартную (java, .net, parrot и т.д.) виртуальную машину. Нежули увеличение до 100кб так сильно сказывается на стоимости устройства? Может стоит съэконосить на велосипедах (своих VM), немного потеряв на чуть более дорогом железе? Мой опыт показывает, что чем стандартнее софт в железке, тем качественнее оказывается конечный продукт, а проект завершается без серьезных срывов сроков.
Но Вам виднее.
Посмотрите на TCL. Пример достаточно маленького (но все равно недостаточно маленького для Вас) интерпретатора можно увидеть на http://tinytcl.sourceforge.net/index.html
HC>Откровенно говоря 32 и 40 кб (+ еще 3кб) — это колоссальный ресурс. Не думаю, что вы в него уложите стандартную (java, .net, parrot и т.д.) виртуальную машину. Нежули увеличение до 100кб так сильно сказывается на стоимости устройства?
Что не уложить parrot я уже знаю; уложить java-машину, я думаю, можно, единственное, что не хочется писать менеджер памяти. Еще одна проблема — разрядность арифметики, parrot, как я смутно помню, 32-битный.
HC>Может стоит съэконосить на велосипедах (своих VM), немного потеряв на чуть более дорогом железе? Мой опыт показывает, что чем HC>стандартнее софт в железке, тем качественнее оказывается конечный продукт, а проект завершается без серьезных срывов сроков.
Как показал опыт, стоимость разработки своей VM пренебрежимо мала по сравнению со стоимостью разработки железа; Кроме того текущая платформа — это не наша разработка, разработка нашей идет, но в течение полугода оно не появится, а запускаться надо. Кроме того, нельзя не учесть факт, что чем более мощные процессоры используются (больше памяти — более мощный процессор), тем хуже у них с энергопотреблением. К тому же на более мощные платформы уже портированы какие-либо высокоуровневые решения, типа Java или Lua, и даже есть, как правило, ОС. Но энергопотребление таково, что говорить об автономном применении не приходится.
V>В качестве программы-минимума, хотя бы какой-нибудь неплохой язык и парсер его в AST, но отдельно стоящий, т.е. что бы не приходилось выдирать его из LUA, V>а можно было просто взять и использовать, в этом случае хорошо бы что бы язык и компилятор были реализованы на каком-нибудь человеческом языке, а не С/С++/Java, V>тк придется дописывать трансляцию в байткоды, и нет столько времени, что бы ковыряться с чужим кодом на вышеозначенных языках.
Не совсем понятно, что такое "человеческий язык". Но идея такая, что когда-то была на свете такая архитектура MSX, и там таки был компилятор Tiny C, это называлось, кажется. Кажется симантековский. Там был так называемый T-code, который сам по себе был языком + куча компиляторов из C, Pascal, FORTRAN и т. д. в этот самый T-code + кодогенератор из T-code в .Z80.
Соответственно, если вдруг сможете найти это изделие, то интерпретатор T-code на Fort напишете легко, а фронт-энд компиляторы, и как раз под 8-битную платформу, соответсвующих ("8-битных) версий языка у вас как раз будут готовые...
V>Бэкграунд: смотрел PyPy, за отведенное время не осилил (вероятно, к нему еще вернусь, тк выглядит как почти то, что надо, но непонятно как это использовать). V>Смотрел LLVM, не портируемо (куда нам надо). Смотрел Parrot, сложно и не портируемо.
V>Мнения?
V>--- V>dmz
V>если модераторы восстановят пароль от моего старого аккаунта, я буду совсем не против
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, voidlizard, Вы писали:
V>Forth, при всех своих достоинствах, язык несколько жутковатый, к тому же его подход заставляет решать множество проблем, V>которые в нормальной жизни обычно не возникают. Грубо говоря, бывают языки, которые стремятся сократить побочные эффекты, V>а бывают языки, которые строятся из побочных эффектов (это про форт). Соответственно, в следующем поколении устройств V>хочется переехать с форта на что нибудь еще.
Вот и зря. Компактность программ на Форте неимоверно высока из-за побочных эффеков, а именно — из-за "гуляния" стека. Слова прикладной программы разрабатываются таким образом, чтобы быть операндами для следующих слов, и исключить доп. загрузки и преобразования м/у вызовами т.е. момент такого вот стекового дизайна присутствует. Другие языки ориентируются на "чистый" стек, что подразумевает дополнительные операции по загрузке агрументов ф-ий и прочистке стека в конце ф-ий.
Но если всё-таки хочется именно "нормальный" язык, а размером программы можно пренебречь, то могу подкинуть интересную идею относительно C#. Что если использовать обычный .Net? Он порождает опкоды, которые предназначены как раз для стековой машинки, их интерпретировать — одно удовольствие. Понятное дело, что напрямую это очень дорого, поэтому делаем так:
пишется программа, которая вообще не использует библиотеки дотнета. Т.е. используются только простые типы и свои объекты, порождённые от object.
На саму программу наложить ограничения, типа:
— не использовать интерфейсы
— не создавать виртуальных ф-ий
— не вызывать базовые виртуальные методы Object
— не использовать никаких внешних референсов (ну, кроме может своеё же либы — чуть ниже об этом).
— не ссылаться на mscorlib
Т.е. можно писать и отлаживать прямо в студии.
Затем скомпиллировать в dll.
Затем, использовать один из тулзов, чтобы выдрать из PE метаданные и сами опкоды тел методов (плагин к Reflector-у написать, например). Затем надо пройтись по опкодам, проверить на наличие инструкций виртуальный вызовов, типов-интерфейсов и т.д. Тоже самое сделать на все ссылаемые методы из некоей "своей" библиотечной либы. Построить граф зависимостей, и исключить невызываемые методы из своей программы в т.ч.
Если удачно — то трансформировать опкоды и разресолвить все ссылки относительно некоего начального фиксированного адреса. Трансформация нужна в любом случае, т.к. разрядность машин разная, к тому же будут инструкции, которые не нужны и т.д.
Например, если проц. 8-ми разрядный, то из всех опкодов надо оставить только операции с byte и sbyte (short-версии). Если надо делать свою 16-ти разрядную арифметику, то, надо написать свою структуру из 2-х полей и переопределить операции + — * / по ней. Трансформированный опкод залить во флешку.
До этого написать эмулятор преобразованного опкода для целей тестирования.
В общем, такое вот предложение.
Кстати, в своё время я активно думал над типизированной версией Форта. Т.е. ввести типы, ввести указатели, для каждого слова явно указывать в терминах типов состояние стека до и после вызова.
Компилятор пусть анализирует код и выдаёт ошибку компиляции, если состояние стека не соответствует заявленному перед вызовом других слов, или перед выходом из слова. Линейный анализ очень просто. Для нелинейного есть несколько простых правил:
— если есть ветвление, то по всем веткам ветвления должны быть одинаковые конечные состояния стеков
— если есть циклы, то стек на начало и конец тела цикла должен быть одинаков.
Таким образом, мы отказываемся от алгоритмов в программе, где в стеке происходит недетерминированное динамическое выделение неизвестного на момент компиляции кол-ва ячеек, что есть гут. Сами компиляторы под стекоподобные языки можно писать на самом же Форте, используя его immediate слова.
Синтаксис объявления типа грубо такой (при некоторых предопределённых типах):
:type Node
int value
ptr* Node next
;
Таким образом, тип — это последовательность данных на стеке или в памяти.
В этом примере на стеке до вызова лежит (Node arg1, Node* arg2), слово делает arg1.next=arg2
"[[" — для примера некое служебное imeddiate слово, которое добавляет сигнатуру к слову. Если слово не изменяет стек, сигнатуру можно не указывать.
Можно подумать и над методами экземпляров прямо внутри типов, там при аннотации всегда предполагать, что на вершине стека будет указатель на экземпляр.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, voidlizard, Вы писали:
V>Кстати, в своё время я активно думал над типизированной версией Форта. Т.е. ввести типы, ввести указатели, для каждого слова явно указывать в терминах типов состояние стека до и после вызова.
V>пишется программа, которая вообще не использует библиотеки дотнета. Т.е. используются только простые типы и свои объекты, порождённые от object. V>На саму программу наложить ограничения, типа: V>- не использовать интерфейсы V>- не создавать виртуальных ф-ий V>- не вызывать базовые виртуальные методы Object V>- не использовать никаких внешних референсов (ну, кроме может своеё же либы — чуть ниже об этом). V>- не ссылаться на mscorlib
V>До этого написать эмулятор преобразованного опкода для целей тестирования. V>В общем, такое вот предложение.
Не многовато ли сложностей — по сути, у нас останется парсер языка и все — бекенд придется делать свой, да и рантайм тоже. В принципе
парсер не самое сложное, в том же хаскелле есть пяток парсеров разных языков, включая какой-то функциональный и Lua. Интереснее какие
языки нормально ложатся на стековую машину без управления указателем стека — т.е. я пока не представляю, как на фортовской VM сделать,
например, локальные переменные поверх стека данных, без того что бы устраивать свой стек локальных переменных на хипе (дорого).
Т.е надо отличать обычные стековые машины — которые своим стеком управляют, перемещая указатель на вершину и создавая/освобождая фреймы,
и форт, который стеком пользуется но не управляет. Пока у меня, с подачи palm mute есть надежда, что поверх этой VM может работать
какой-нибудь из функциональных языков, но полной уверенности нет — надо изучать.
dmz>Т.е надо отличать обычные стековые машины — которые своим стеком управляют, перемещая указатель на вершину и создавая/освобождая фреймы, dmz>и форт, который стеком пользуется но не управляет. Пока у меня, с подачи palm mute есть надежда, что поверх этой VM может работать dmz>какой-нибудь из функциональных языков, но полной уверенности нет — надо изучать.
Почитал я спецификацию проца и не понял, в чём проблема-то? Есть FSR регистры, один из них можно использовать для текущего указателя стека данных в быстрой памяти. Прикольные регистры PREINC и POSTDEC позволяют красиво организовать аналог push и pop данных. В качестве стека возвратов форт-машинки можно использовать родной стек, благо что он позволяет читать и писать в его вершину, а глубина подпрограммы интерпретатора явно не должна быть. В общем, так и не понял, в чём проблема выделять целые фреймы в стеке. Передвинул адрес в FSR и всё.
Т.к. этих FSR как минимум 2, один из них (FSR0) можно использовать как вершину стека, а другой (FSR1) — для непосредственной адресации стека. Для такой схемы нужен стандартный пролог высокоуровневой ф-ии, т.е. нужен регистр, который хранит вершину стека на момент входа в ф-ию (это будет обычная глобальная переменная, назовём её BP). Если вызываемая ф-ия имеет локальные переменные, то надо в стек поместить значение BP, а в BP поместить текущий указатель стека (FSR0). Далее просто, например опкод хочет загрузить локальную переменную на вершину стека, тогда к BP прибавляется локальный адрес переменной, результат помещается в FSR1, и читается INDF1.
Могу предложить вообще простое решение:
смотри, у тебя в распоряжении 15 банков памяти. Ну, один из них под память виртуальной машины и под глобальные переменные пользовательской программы, еще один — системный, еще один — под вычислительный стек данных. Остаётся 13 банков памяти. Так вот, внимание... Пусть для каждой пользовательской ф-ии локальный фрейм всегда начинается с 0-ля (т.е. будешь иметь прямую адресацию фреймовых переменных), а перед входом в неё — инкрементировать BSR.
Вообще, я бы покумекал над этим. Смотри, далеко не все ф-ии (слова) используют локальные переменные, т.е. реально вложенность подпрограмм может быть больше 13-ти. Далее, надо смотреть, начиная от наиболее вызываемых ф-ий, возможно, что локальный фрейм этих ф-ий удасться разместить в том же банке после локального фрейма вызывающих ф-ий (т.е. по прежнему имеем прямую адресацию, но бэкенд должен скорректировать адреса в опкодах).
V>Почитал я спецификацию проца и не понял, в чём проблема-то?
Проблема в том, что 1) все регистры заняты под другие цели — тк работает не только форт-машина, но и ядро прошивки 2) это будет уже не форт машина. Уже реализован некий аналог F21 c расширенным набором инструкций, и что бы
переписывать машину нужны веские основания, и хотелось бы при этом иметь спецификации того, что будет реализовываться, как это было с F21 3) Соответственно, главный вопрос в том, какой язык можно скомпилировать в код для имеющейся форт-машины
Здравствуйте, dmz, Вы писали:
V>>Почитал я спецификацию проца и не понял, в чём проблема-то?
dmz>Проблема в том, что 1) все регистры заняты под другие цели — тк работает не только форт-машина, но и ядро прошивки 2) это будет уже не форт машина. Уже реализован некий аналог F21 c расширенным набором инструкций, и что бы dmz>переписывать машину нужны веские основания, и хотелось бы при этом иметь спецификации того, что будет реализовываться, как это было с F21 3) Соответственно, главный вопрос в том, какой язык можно скомпилировать в код для имеющейся форт-машины
Ну дык, если стоит задача не делать ничего нового, тогда в гугл "C to Forth" ...
Здравствуйте, dmz, Вы писали:
Пока у меня, с подачи palm mute есть надежда, что поверх этой VM может работать dmz>какой-нибудь из функциональных языков, но полной уверенности нет — надо изучать.
Пусть для каждой пользовательской ф-ии локальный фрейм всегда начинается с 0-ля (т.е. будешь иметь прямую адресацию фреймовых переменных), а перед входом в неё — инкрементировать BSR. 
