Здравствуйте, dmz, Вы писали:
dmz>Ну а что тут рассказывать? Более приятный и современный синтаксис. Более обширная и продуманная стандартная dmz>библиотека, которая не менее важна, чем язык. Даже несмотря на то, что для OCaml есть ExtLib, без которой dmz>вообще невозможно работать, все равно приходится все дописывать. Хаскелл — более консистентный.
OCaml вообще коряв и безобразен, но он очень прост и на нем легко писать в очень разных стилях, поэтому наверно и живет и поэтому наверно при меньшей популярности на нем пишут (и главное дописывают) намного больше чем на хаскеле.
Здравствуйте, dmz, Вы писали:
dmz>На перле это сделать точно можно, только я забыл какой кракозяброй получить последний элемент массива, который выдает split.
Всё проще, и без кракозябл. $arr[-1] даст последний элемент @arr.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, dmz, Вы писали:
dmz>Исходников они не дают.
Шотландцы!
dmp> Кажется, он интерпретируемый.
Там есть несколько вариантов, например:
The Hume to C compiler (humec) translates HAM instructions
produced by the phamc compiler into portable C code using a template-instantiation approach.
This provides a higher-performance route for deploying Hume code, that has been tested on a
number of platforms, including Linux, MacOSX, the a Renesas M32C development board and the
Tmote Sky. The Renesas board uses a 32-bit embedded microcontroller with 16KB DRAM, the
Tmote Sky is a 16-bit standalone computing device with 8KB of DRAM
dmz>В примерах, собраных для Intel лежат какие-то бинарники с именем dmz>Hume и весом 3 мегабайта, что наводит на мысли.
Это, наверное, компилятор, написанный на Haskell.
dmz>VM Бипа, собранная для Intel — 23 килобайта, если собрать без отладочной информации.
У них есть маленький интерпретатор: hami
Здравствуйте, dmz, Вы писали:
dmz>Для тех кто не в курсе, кратко напомню: Beep (Бип, звук, которым забивают непечатные ругательства в эфире, так как именно их я произнес, когда понял, что мне придется написать этот язык) — это питоно-луа образный язык со статической типизацией и выводом типов, компилируемый в байткод и предназначенный, по замыслу, для скриптования на микроконтроллерах (таких, куда не впихнешь Java и Lua). Является заменой форту. Сейчас он работает на MSP TI430, размер памяти именно на язык определяется размером выделенного хипа и стеков. Сейчас это контроллер с 5K RAM на борту, но будет работать и на 2K — младшие процессоры в линейке.
Здравствуйте, dmz, Вы писали:
dmz>А можно тест для Lua 5.0 ? 5.1 в репозитории нет, а этот скрипт под 5.0 не работает. С питоном сравнивать неспортивно, надо попробовать сравнить с грамотно реализованным языком, к которым я Lua отношу (пока не доказано обратное).
Луа медленнее, чем мог бы быть — потому что принципиально написан на ANSI C.
Если интересно — есть такой ресурс по написанию быстрых VM: http://www.complang.tuwien.ac.at/projects/interpreters.html
Код для луа 5.0.x:
--// lua 5.0.x
local byte, sub = string.byte,string.sub
local COMMA, STAR = byte(","), byte("*")
local function nmea_parse_gga(s)
local result, j, comma = {}, 1, 0
local len = string.len(s)
for i=1,len do
local c = byte(s,i)
if c == COMMA then
comma = comma + 1
if comma == 2 then result.time_utc = sub(s,j,i-1)
elseif comma == 3 then result.lat = sub(s,j,i-1)
elseif comma == 4 then result.lat_semi = sub(s,j,i-1)
elseif comma == 5 then result.lon = sub(s,j,i-1)
elseif comma == 6 then result.lon_semi = sub(s,j,i-1)
elseif comma == 7 then result.fix = sub(s,j,i-1)
elseif comma == 8 then result.sat = sub(s,j,i-1)
end
j = i+1
elseif c == STAR then
break
end
end
return result
end
--// TEST:
local s = "$GPGGA,121505,4807.038,N,01131.324,E,1,08,0,9133.4,M,46.9,M,,*42"
local N = 65535
for i=1,N do
local gga = nmea_parse_gga(s)
assert( gga.time_utc == "121505"
and gga.sat == "08"
and gga.fix == "1"
and gga.lat == "4807.038"
and gga.lat_semi == "N"
and gga.lon == "01131.324"
and gga.lon_semi == "E")
--// print(gga.time_utc)
--// print(gga.sat)
--// print(gga.fix)
--// print(gga.lat)
--// print(gga.lat_semi)
--// print(gga.lon)
--// print(gga.lon_semi)
end
Здравствуйте, dmz, Вы писали:
C>>Расскажи как тебе это удалось!! dmz>Это элементарно. Даже когда я на нем активно программил (включая perlguts-xs, ЕВПОЧЯ), году так в 2002ом, dmz>то и то не мог в каждый момент уверенно сказать какую кракозябру когда применить, а так же, когда имею дело со ссылкой, dmz>а когда со значением. Все вот эти $@# и скалярно-векторные контексты крайне задалбывали. Особенно запомнился момент, когда я после нескольких часов бодания просто тупо один в один переписал работу с какой-то сложной вложенной структурой данных на питоне, и оно сразу заработало правильно, просто в силу того, что там негде было накосячить с пресловутыми контекстами.
Вот-вот. Мне программы на нём до сих пор снятся
dmz>Мне надо написать фильтр для шелла, который отфильтрует по строке, отцепит крайние значение (таймстемп), и dmz>результаты просуммирует. Можно это сделать коротким однострочником на питоне?
На шэле точно можно: "cat yourfile | sed s/^.*\.//g | sum"
CS>Собственно цифры важны за для понять стоит ли овчина выделки. CS>Я имею ввиду компиляцию с оптимизацией по типам.
Собственно, никакой язык кроме статического в целевую платформу просто не влезет.
Так как если мы вынуждены хранить информацию о типе объекта для каждого объекта,
это автоматически означает, что каждый объект сразу занимает 32 бита вместо 16.
И еще вот что — я готов писать сколь угодно сложный компилятор на нормальном языке типа окамла или
хаскелла, но я категорически не готов писать сколько-нибудь сложную VM на языке С. Вообще не готов писать что-то сложное
на языках уровнем ниже определенного. Я год назад вообще думал, что я не готов что-то писать что-либо на чем-либо вообще.
Я просто обязательно где-нибудь ошибусь, и если потом в серийных проданных устройствах будут периодические
креши — это будет очень, очень, необратимо плохо. Так что единственный способ обойтись из очень продолжительного
тестирования — это поддержать VM в как можно более простом состоянии и с минимумом функций.
CS>Вот статья с DDJ Embedded про язык BOB CS>А чего бы не взять скажем TinyVM (писана для Lego Mindstorms) http://tinyvm.sourceforge.net/ CS>Это JavaVM т.е. можно использовать Java compilers прооптимизированные по самое нихочу.
А есть еще NanoVM, PicoVM, NekoVM. Еще есть PIC16FORTH, PIC18FORTH, пачка схем ,и много другого. Их я
изучал тоже. Еще я усиленно ковырял Lua на предмет встраивания.
1) Я рассмотрел все языки, которые нашел на момент до начала компилятора
2) TinyVM не влезало в минимальную целевую платформу (PIC18) на момент начала разработки
3) JavaCard и тот, по моему, не влезал
4) Есть еще цель — получить максимально компактный байткод, так как он будет грузиться по каналам.
Так вот конкретно про Java, не надо думать, что там нормальная джава. Там НЕ нормальная джава, и какими-то
конструкциями пользоваться нельзя. Во что это "нельзя" выливается я не знаю — либо они в байткоде анализируют
невалидные инструкции, либо просто их не реализуют в VM — с непредсказуемым результатом. Более того, если
потребуется вносить какие-то изменения в компилятор или VM — а потребуется почти наверняка — то любая возня
на низкоуровневых языках сразу приведет к тому, что дешевле написать свое с нуля.
То есть я утверждаю, что изучить чужой компилятор и VM на уровне, достаточном для того, что бы уверенно вносить туда
изменения — эквивалентно его написанию, причем написанию на каком-нибудь, скажем мягко, так-себе языке.
Для примера — у меня тут лежат исходники двух языков с выводом типов — Boo на C# и Haxe на NekoML и окамле.
Так, система типов Boo — это 107 файлов и 15759 строк / 479001 символов и я даже пытаться не стал ее понять.
И там, собственно, вывод типов занимает экрана полтора и понятен настолько, что его можно использовать как шпаргалку.
Думаю, что в систему типов Boo я бы въезжал дольше, чем писал весь свой компилятор.
Так что я думаю, что решение написать свое — оказалось вполне адекватно. Типы + компиляция + кодогенерация — 1022 строки на окамле. Это немного.
Думаю адаптация любого друго решения, и особенно, уплотнение байткода (а в планах — вплоть до хаффмановских кодов) — заняла бы просто тупо больше времени. И окончилась бы форком и поддержкой большого чужого проекта на каком-нибудь неподходящем языке.
Вообще, все как сговорились компиляторы (Компиляторы!!! — не тайм-критикал системы!) писать на си. Когда с девяностых годов существует хотя бы Окамл.
И вообще мне получившийся в результате язык нравится больше джавы, уж для целей мелкого скриптинга уровня "если по машине долбанули кувалдой — то послать смс с ахтунгом" — то точно. Так что я выкидывать его не буду, а наоборот, сделаю оптимизацию хвостовой рекурсии и может, генерацию нативного кода — получится вообще приличный язык.
Tmote Sky is a 16-bit standalone computing device with 8KB of DRAM
У MSP430F1611 2K килобайта RAM... И я думаю, что все это поделие туда влезет.
А если выкинуть операционную систему FreeRTOS, которая занимается тредами — которых два —
в одном работает скрипт, во втором мигает диод, что бы мне было не скучно — и вообще
памяти нужно будет только на буфера ввода-вывода, стеки и хип.
dmz>>В примерах, собраных для Intel лежат какие-то бинарники с именем dmz>>Hume и весом 3 мегабайта, что наводит на мысли. Z>Это, наверное, компилятор, написанный на Haskell.
Z>У них есть маленький интерпретатор: hami
Если он интерпретирует текст, то это сразу его вычеркивает, так как плотность любого текста гораздо ниже
плотности стекового байткода. А это критично. Так как в некоторых случаях скрипты придется заливать по смс.
Да и ну их вообще. Я и не думал вовсе, что я единственный человек в мире, который написал vm для всяких мелких девайсов.
И вообще, в силу того, что похоже на питон и луа, то есть внешне простое — я думаю, ко мне быстрее народ потянется.
Если я пойму, что это хоть кому-то нужно, я это выложу в опенсорц. В принципе получилось нечто такое, что уже жалко будет
выбросить или забыть.
1.5s. Луа крут. На ANSI C они его, написали, наверное, зря. Точнее так — надо было сделать версию для GCC и версию ANSI,
дефайнами перекрыть или еще как. GCC поддерживает label as values, что дает возможность наиболее быстрой интерпретации
Token-threaded code, каковой и используется в Beep, и, кажется, в Lua.
У меня есть исследование одних товарищей, они там анализируют различные способы интерпретации и приходят к выводу,
что способ интерпретации такого вида:
goto *instruction[code[++ip]];
быстрейший из возможных для такого рода байткода (что довольно предсказуемо).
Цикл выборки отсутствует, в конце каждой команды — находится выборка следующей.
Здравствуйте, dmz, Вы писали:
dmz>Если я пойму, что это хоть кому-то нужно, я это выложу в опенсорц. В принципе получилось нечто такое, что уже жалко будет dmz>выбросить или забыть.
Выкладывай. По крайней мере, просто даже почитать код будет интересно.
Здравствуйте, dmz, Вы писали:
dmz>1.5s. Луа крут. На ANSI C они его, написали, наверное, зря. Точнее так — надо было сделать версию для GCC и версию ANSI, dmz>дефайнами перекрыть или еще как. GCC поддерживает label as values, что дает возможность наиболее быстрой интерпретации
Это так, но авторы точно не будут этого делать
Автор luajit грозится переписать VM на ассемблере (и изменить байткод) — обещает без jit 200-400% ускорения на типичных операциях.
Ну и если переписать тест в луа-стиле c паттернами будет еще в 2-2.5 раза быстрее.
--// Lua 5.0.x
local gfind = string.gfind
local fields = {
"header","time_utc","lat","lat_semi","lon","lon_semi","fix","sat"
}
local function nmea_parse_gga(s)
local obj, comma = {}, 0
for data, sep in gfind(s,"([^,*]*)([,*])") do
comma = comma + 1
if sep == "*" or comma > 8 then break end
obj[fields[comma]] = data
end
return obj
end
--// TEST:
local s = "$GPGGA,121505,4807.038,N,01131.324,E,1,08,0,9133.4,M,46.9,M,,*42"
local N = 65535
for i=1,N do
local gga = nmea_parse_gga(s)
assert( gga.time_utc == "121505"
and gga.sat == "08"
and gga.fix == "1"
and gga.lat == "4807.038"
and gga.lat_semi == "N"
and gga.lon == "01131.324"
and gga.lon_semi == "E")
--// print(gga.time_utc)
--// print(gga.sat)
--// print(gga.fix)
--// print(gga.lat)
--// print(gga.lat_semi)
--// print(gga.lon)
--// print(gga.lon_semi)
end
T>>Интересно. T>>Расскажешь? dmz>Ну а что тут рассказывать? Более приятный и современный синтаксис. Более обширная и продуманная стандартная dmz>библиотека, которая не менее важна, чем язык. Даже несмотря на то, что для OCaml есть ExtLib, без которой dmz>вообще невозможно работать, все равно приходится все дописывать. Хаскелл — более консистентный.
Соглашусь.
Последовательность соблюдения решений очень важна.
На многословном, но последовательном тикле удаётся писать быстрее, чем на кратком, но... разнообразном перле.
dmz>Но с другой стороны — я уже напоролся на проблемы производительности и пришлось существенно напрячься, что бы ускорить компиляцию, и не допускать что бы она была не более одной секунды на скрипт, который в состоянии написать человек. И вот как бы тут повел себя хаскелл — я не знаю.
Уверяю тебя, ты был бы достаточно приятно удивлён.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
FR>OCaml вообще коряв и безобразен, но он очень прост и на нем легко писать в очень разных стилях, поэтому наверно и живет и поэтому наверно при меньшей популярности на нем пишут (и главное дописывают) намного больше чем на хаскеле.
А вот новое пишут...
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
dmz>У меня есть исследование одних товарищей, они там анализируют различные способы интерпретации и приходят к выводу, dmz>что способ интерпретации такого вида:
dmz>
dmz> goto *instruction[code[++ip]];
dmz>
dmz>быстрейший из возможных для такого рода байткода (что довольно предсказуемо). dmz>Цикл выборки отсутствует, в конце каждой команды — находится выборка следующей.
Ассемблер круче. А реализация на нём main loop интерпретатора байткода — неделя работы.
Если вкратце — то стеково-регистровая, два стека — данных и возвратов, регистры: указатель фрейма и tmp. tmp используется, когда
нужно избежать лишних манипуляций со стеками (в форте обычно используют регистр R для этого, что приводит к чудесным расколбасам —
например, если попробуете сделать exit изнутри цикла, счетчик которого находится в регистре R — будете очень удивлены).
На стек возвратов кладется адрес возврата функции и смещение текущего фрейма стека данных. Свободного доступа к регистру возвратов
R нет, его могут писать/читать только инструкции вызова и сохранения/восстановления фрейма. Текущий фрейм стека данных сохраняется,
что бы 1) были простые прологи/эпилоги функций 2) что бы переживать ситуацию, когда какие-то вычисления его загадили. В принципе
сейчас третья версия компилятора не дает возможности гадить в стек (те производить вычисления, которые имеют тип отличный от void и
которые ничему не присваиваются или не участвуют в выражении — но нативные функции могут гадить как им вздумается).
Стек данных разбит на фреймы, фрейм создается при вызове функции. Есть операции доступа к ячейкам стека относительно указателя фрейма —
т.е возможность изменить данные вне своего фрейма — отсутствует. Восемь ячеек выделены, и для доступа к ним используются однобайтные
операции — LOAD0 ... LOAD8, STORE0 .. STORE8. Для остальных есть литеральные команды LOADF, STOREF (передается смещение ячейки от начала фрейма).
Выделенные ячейки можно (и нужно) кэшировать в регистрах, и это легко сделать. Кроме того их можно сделать больше, так как пока
задействована 71 команда из 256 возможных.
Глобальных мутабельных данных нет. Константы времени компиляции хранятся в байткоде (program flash), в хип не грузятся. Program flash у нас
много, 30 — 80 килобайт, а вот хипа мало.
Хип. Хип организован как последовательность блоков, 16 бит на заголовок, размер блока, признак занятости и отметки GC. Таким образом, выделение нового блока — O(количество блоков). Алгоритм поиска — ищем подходящий свободный блок наименьшего размера, т.е. наверное типа O(2N). Это не очень хорошо, но так как хипа мало, то нестрашно. Я знаю как сделать за O(1), но нужна будет доп. таблица и вообще это потом, и так нормально.
Память адресуется строго словами. Никакой байтовой адресации. Это ускоряет сборщик минимум в два раза, и все остальное тоже сильно ускоряет.
Данные на хипе пока немутабельны. Это и хорошо и плохо, пока не знаю на чем остановиться. Если будут мутабельны — то пропадет возможность рилтаймовой сборки мусора, если будут немутабельны — то будет тормозить ряд вещей. В общем, это пока под вопросом.
Сборщик мусора — консервативный, трехцветный. Поскольку памяти для него нет, то дерево объектов обходится где-то квадратично. Это плохо, но
поскольку хипа мало, то не очень. Техника реверсирования указателей потребует место для хранения указателя в заголовке каждого блока, в общем, я не стал.
Но. Поскольку нет глобальных мутабельных данных, то периметр сборщика мусора ограничивается текущей глубиной стека данных. Соответственно, в некоторые моменты мы память можем освободить за O(1). В общем, тесты показывают, что большую часть времени оно так и работает;
серьезно нагнуть его можно, только если забить стек данными похожими на адреса — но это надо как-то специально постараться.
Типы данных — инт (он же используется для символов), так что если зачем нибудь понадобится поддержка юникода — то она будет бесплатной.
Все, что не помещается в инт — это ссылка на объект в хипе.
Строки — отдельная структура, для экономии один символ — один байт, накладные расходы на строку — слово на размер плюс остаток от деления количества символов на 2.
Туплы, списки — классические. Пробовал сделать VList, но накладные расходы для обоих подходов таковы, что проще оказалось пока на это забить.
Поскольку функции уже неделю как первоклассные значения, добавились операции вызова по переменному адресу — теперь это не очень страшно. Поскольку в рантайме никаких проверок валидности данных на стеке не делается почти ни для чего — добавлять такие операции без типизации этого дела было очень стремно.
Как-то так. Машина частично инспирирована джавовской, но попроще. Кстати, JVM сделана по-уму, и сравнительные отзывы о ней хорошие.
Как-то так. Вкратце получилось подробнее, чем у меня на вики
M>Ассемблер круче. А реализация на нём main loop интерпретатора байткода — неделя работы.
Так нету, main loop-а то.
И в топку ассемблер. Есть у меня ассемблерная реализация для старой версии для PIC18 — еще для форта — и что с ней делать?
Платформа сменилась, несколько месяцев работы разработчика и деньги, ему заплаченные — выкинуты.
Трекеров в мире куча, все на чем попало, но си есть под каждый.
Да и не думаю я, что результаты будут сильно отличаться от си. Можно подумать, что goto *instruction[code[++p]] может скомпилироваться во что-то другое, чем то, чем оно является. Данные по регистрам gcc и так успешно распихивает. Да и производительность скрипта вообще почти неважна, если
честно. По первоначальной задумке. Правда теперь возникают мысли, что надо допилить VM до доступа к портам ввода-вывода, сделать сборку мусора рилтаймовой, сделать пре-компиляцию в нативный код (преобразованием token threading в code threading), рилтаймовый сборщик мусора и зеленые треды.
И забить даже на си.
dmz>> 2) по удобству использования они могут не уступать динамическим.
M>А вот это верно, видимо, толко для микроконтроллеров
Ой ли? У меня есть пример разработки почти одного и того же проекта на питоне и на ocaml.
На питоне — транслятор форта. На окамле — компилятор бипа. На питоне кода получилось в разы
больше, а функцинальности — в разы меньше. Более того, компилятор бипа на питоне я бы (не говоря о том, что не написал бы никогда) —
писал бы год, большую часть времени отлаживаясь и гоняя юнит тесты (которые бы тоже надо было написать и поддерживать в актуальном состоянии).
Динамическая типизация, я уверен, появилась не то того, что она очень нужна — а от того, что именно такую
типизацию проще всего сделать. Местами она может и нужна, но таких мест меньшинство.
M>Как, кстати, в Beep виртуальные методы реализуются?
Так же как и везде — vtbl. Только я думаю, что ОО не стоит того, что бы ради него как-то напрягаться. Мелкая, частная,
ограниченно-полезная концепция (c) Луговский.
Т.е. если когда нибудь в бипе будут макросы — то объектная ориентированность будет реализована именно ими, именно
теми, кому она зачем-то понадобилась.
Здравствуйте, c-smile, Вы писали:
CS>runtime обязан сначала просканировать класс, а потом сам объект. CS>Т.е. имеем как минимум 2*O(1).
2*O(1) == O(1)
Точнее "2*O(1)" — это какое-то недоразумение. O(1) — означает константное время доступа, т.е. не изменяемое при увеличении количества элементов в коллекции и т.п. О том же сколько времени займет доступ O-нотация информации не дает. Ее задача описать масштабируемость алгоритма, а не его скорость.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
dmz>>> 2) по удобству использования они могут не уступать динамическим.
M>>А вот это верно, видимо, толко для микроконтроллеров
dmz>Ой ли? У меня есть пример разработки почти одного и того же проекта на питоне и на ocaml. dmz>На питоне — транслятор форта. На окамле — компилятор бипа. На питоне кода получилось в разы dmz>больше, а функцинальности — в разы меньше.
Очень может быть, что это просто личные предпочтения, как с Перлом, например
Кстати, у меня с Перлом примерно аналогичные взаимоотношения.
А вот в Питоне реально нравится возможность делать так
def factory( **kwa ):
def g():
for i in kwa['a']:
if i % 2:
yield i*i
return g
b = factory( a=[1,2,3,4,5] )
или практически тоже самое
a = [1,2,3,4,5]
b = (i*i for i in a if i % 2)
Надеюсь когда-нибудь увидеть Биип на каком-нибудь сорфорже или гуглекоде.
Если практически и не требуется, то по крайней мере познавательно.
