Здравствуйте, 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>Для одного из проектов с использованием 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>В качестве программы-минимума, хотя бы какой-нибудь неплохой язык и парсер его в 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. 
