Ответ Javе и Flash'у [тема для программеров]

[NightRadio]

библиотеки писать либо на чистом Пикси, либо натравить какой-нибудь Си-компилятор на пикси байт-код :) Хотя тут конечно скорость очень критичным фактором становится, особенно если аудио/видео библиотечки.. так что этот вопрос открыт.
OpenGL сначала самый основной прикрутить, а потом постепенно расширять. Тут вопрос в том, что OpenGL не очень вяжется с текущей идеологией графики в Пикси. Я бы сказал, графическая часть Pixilang более гибкая по некоторым показателям и сделать тоже самое с использованием GL довольно затруднительно... В pixi полная свобода: создал картинку, тут же записал в неё что-то, тут же нарисовал её в саму себя (!). А в GL картинку сначала рисуем, а потом уже отдаем в руки граф. ускорителя..

[NightRadio]

Итак. Готов поделиться первыми результатами :)

Рабочее название проекта - warmcode.
В основе - компактная виртуальная машина, нацеленная на мультимедийные приложения и несложные языки программирования (Pixilang, Си и другие).
План такой:
1) Доведение до ума байт-кода;
2) Реализация виртуальной машины;
3) Написание первых тестовых приложений на warmcode-ассемблере; в том числе - загрузчик или загрузочная микроОС;
4) Портирование компиляторов Pixilang и Си для компиляции в формат warmcode. Си понадобится для компиляции в наш байт-код некоторых мультимедийных библиотек, типа Jpeg и GIF.

Спецификация виртуальной машины warmcode. Версия 0.001.
Машина содержит 256 32-битных (а в будущем, возможно, 64-битных) регистров r0...r255
Память состоит из динамически-выделяемых блоков. Блок выделяется командой alloc, удаляется - командой free. Адресация линейная.
Два блока памяти выделяются автоматически при запуске машины. Это BOOT (блок с загрузочным кодом) и STACK (блок со стеком).
Описание инструкций байт-кода:

Code: Select all

nop
mov r,r
mov8 r,const8
mov16 r,const16
mov32 r,const32
mov r,BOOT
mov r,STACK
#####################
## CONVERT         ##
#####################
si8toi r,r //signed int 8 -> 32
si16toi r,r //signed int 16 -> 32
#####################
## MEMORY          ##
#####################
//alloc - create new memory block. ret value - memory pointer.
alloc r,r
realloc r,r
getsize r,r
free r
store8 r,r //aligned
store16 r,r //aligned
store32 r,r //aligned
load8 r,r //aligned
load16 r,r //aligned
load32 r,r //aligned
#####################
## MATH            ##
#####################
add r,r,r
sub r,r,r
mul r,r,r
div r,r,r
rem r,r,r
smul r,r,r
sdiv r,r,r
srem r,r,r
inc r
dec r
#####################
## BITS            ##
#####################
and r,r,r
xor r,r,r
or r,r,r
sr r,r,r //Shift right
ssr r,r,r //Signed shift right
sl r,r,r //Shift left
ssl r,r,r //Signed shift left
#####################
## JMP             ##
#####################
rjmp8 const8 //relative jump
rjmp16 const16 //relative jump
rjmp32 const32 //relative jump
jmp r //absolute jump
rjmpXX r,r,const8 //relative jump if condition XX is true.
  conditions XX: <, <=, >, >=, ==, !=
call r 
syscall const16 //system function call
getsys r,"null terminated string" //get number of system function by name
#####################
## STACK           ##
#####################
push r
pop r
ret
#####################
## FLOATING POINT  ##
#####################
ftoi r,r
ftosi r,r
itof r,r
sitof r,r
fadd r,r,r
fsub r,r,r
fmul r,r,r
fdiv r,r,r
frem r,r,r

Список системных функций еще определяется. В него должны войти команды для работы со следующими компонентами:
1) текстовая консоль;
2) графический ускоритель;
3) звук;
4) клавиатура;
5) мышь;
6) файлы;
7) сеть.

[Zuf]

А как же всякие "мультимедийные" команды? Куда их потом пихать?
Нет циклического сдвига (хотя обычно можно обойтись).
Еесть какойто регистр флагов, я подозреваю?
Зачем по три регистра в математических командах?

Вот еще, не слишком ли специфичные команды получились:
mov r,BOOT
mov r,STACK
Мможет просто положить адреса BOOT и STACK в фиксированные ячейки памяти (скажем в 0-й и 4-й байты)?

PS еще, почемуто меня терзают смутные сомнения, что на таком ограниченном наборе команд не получить большой скорости на современных процессорах. Т.е. не удатся полностью раскрыть потенциал современных процессоров.

[NightRadio]

Мультимедийные команды я пока вижу, как системные вызовы при помощи команд syscall и getsys.
На счет циклического сдвига думал, но не увидел в нем особой необходимости. Как правило полезными являются обычные арифметические сдвиги.
Регистр флагов я решил не делать, а вместо них ввести одну команду "rjmpXX r1,r2,const8". XX - какая-то условная операция. Типа если r1 XX r2, то переход на const8.
Три регистра в мат. командах - это правило RISC архитектуры, которую я взял за базу. Хотя x86 оперирует в основном 2мя операндами, а вот ARM, PowerPC - там уже с тремя можно.
На счет boot и stack возможно ты прав. Подумаю над этим.

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

[Zuf]

Мультимедийные команды я имел в виду процессорные: MMX, SSE и т.п.. Разве эффективно для этого использовать syscall и getsys?

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

А по какому принципу будет производится "уплотнение" кода?

Вообще говоря, все мои опасения связаны с желанием получить максимальную производительность, чтобы можно было в виртуальной машине делать достаточно ресурсоемкие вещи, типа текстурирования с перспективной коррекцией и т.п.
Одно из первых, что бы я хотел сделать на warmcode это просмотрщик панорам (в идеале чтобы можно было смотреть прямо в браузере). Я попытался использовать Java с OpenGL, но видимо не очень удачно. Мой апплет не захотел работать на маке, а в винде вообще увел машину в синий экран (хотя под Linux мне удалось достигнуть желаемого). Возлагаю большие надежды на warmcode =)

[NightRadio]

На счет MMX и SSE еще точно не решил. Я хорошенько изучу эти расширения и попробую составить список соответсвующих команд для WC.

Под уплотнением я имел в виду некоторую оптимизацию по размеру кода. Например. Даны две инструкции:
1) r1 = 66
2) r2 = r2 + r1
После компиляции в коды процессора ARM скорее всего все так и останется :) В зависимости от битности константы.
А вот после компиляции к коды x86 можно упаковать эти две инструкции в одну:
1) r2 = r2 + 66

Далее про производительность...
Если нам нужен 100% быстрый код с максимальной оптимизацией, сравнимой и превосходящей обычные компиляторы, то я вижу только один вариант - библиотека LLVM. Она позволит нам это сделать. Но в этом случае виртуальная машина будет занимать мегабайт эдак 6 как минимум, т.к. в LLVM все очень серьезно и очень наворочено. Естественно, маломощные девайсы и КПК тут сразу отпадают. Я не отвергаю такой вариант - при желании можно обсудить детали. Меня в LLVM смущает лишь то, что машина будет тяжелой и ни о каком минимализме и простоте речи уже идти не может.
Реально простая машина типа warmcode - это другое дело. Она по определению не сможет дать дикой производительности :) Но тут я вижу свои пути оптимизации:
1) поддержка MMX-подобных инструкций. Каких именно, еще не решил. Возможно, тут нужен упор на операции с векторами и матрицами. +инструкции интерполяции;
2) графические команды: рисование текстурированных полигонов с Z-буфером;
3) несложный JIT компилятор, типа как в Pixilang2.

Еще по ходу возник вопрос. Как видно из предложенного мною списка инструкций байт-кода, виртуальная машина изначально небезопасная, т.к. использует простое обращение к памяти по 32-битному указателю - так же, как, например, в Си. Таким образом опять же получаем приличный выигрыш в производительности. Но правильно ли это? Может, указатель описывать двумя значениями дескриптор+смещение и контролировать выход за пределы выделенного блока? Это понизит скорость, но сделает машину более безопасной.

p.s. Java - это да... она такая.. :) Cдает свои позиции...

[Zuf]

Думаю на все эти сомнения можно ответить одним вопросом (такой вот каламбур):
Мы делаем виртуальную машину с уклоном в мультимедийную область использования?
Если да, то тогда многие ограничения и недочеты можно оправдать максимально возможной скоростью работы.

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

[NightRadio]

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

[NightRadio]

Пообщавшись с народом на форуме osrc.info я пришел к выводу, что в случае с мультимедийной виртуальной машиной и нацеленностью на высокую производительность лучше вообще отказаться от байт-кода. За основу стоит взять некий простой и универсальный язык - например, тот, который используется в LLVM, только немного урезанный. А для того, чтобы не производить каждый раз тяжелый лексический анализ выражений, поиск выражений и т.д., код стоит распространять в бинарном формате, который хранит древовидную структуру исходной программы. Такие файлы тяжелее интерпретировать, но зато они хранят в себе абсолютно всю необходимую информацию о исходнике, что позволит при генерации окончательного кода производить качественную оптимизацию. На интерпретацию можно вообще не нацеливаться. Просто грузится бинарный модуль и на лету компилится в код процессора. А если нужна моментальная компиляция - оптимизация просто отключается. Идеальный вариант. Осталось определиться поточнее с языком и бинарным форматом.

[Vlad]

Про PixiLang и человеческую математику.
Если все, что может понадобиться переписывать в коде Пиксилэнга, встает вопрос о скорости обработки кода, так как библиотек будет, думаю, немало. Код в PixiLang и так достаточно вольный и свободный (взять хотя бы быстрое создание функции).
Идея в следущем - если задать более жесткие условия написания кода, то можно избавиться от кучи строковых проверок и прочего (огромный плюс к скорости парсинга файлов). Всякие призы и бонусы в виде упрощенных конструкций кода должны иметь возможность использования только при подключенной библиотеке (на кодах пиксиленга) в которой оно все описано.
Не знаю, насколько оно будет лучше, но при написании скриптового языка этот шаг мне очень помог.

[NightRadio]

Ну скорее всего будет два уровня. Нижний - некий LLVM-подобный язык. Верхний - Pixilang (или другой язык высокого уровня). То есть, к примеру, Pixilang преобразует пользовательскую прогу в инструкции нижнего уровня, а нижний уровень уже генерирует окончательный код для процессора и выполняет его.
Не знаю, стоит ли сильно менять синтаксис Pixilang.. Сейчас нужно придумать язык нижнего уровня.

[NightRadio]

Вчера пришло вот такое письмо от 49@nm.ru.

Здравствуйте Alexandr!
Показалось очень запоздавшим это желание - думаю, что поезд ушел. Да и призывы использовать уникс тоже приведут к тупику = ведь главное , что вы хотите это не потерять для медийности те огромные возможности в железе , которые съедает винда и упомянутые виртуальные машины . Вы же не для себя только это хотите сделать, а раз для народа-так и идите в народ - делайте нечто, что позволит конвертировать любые медиа в код, например, выполняемый с загрузочного CD (с той целью, чтобы писать хоть во флеш хоть в яве, а потом , если появились задержки (до того на них просто не обращать внимания) , то перетранслировать все в загрузочный CD и проблема будет решена = вставил CD перезагрузился и открылся проигрыватель (которые уже есть под Линуксом-как же иначе запустить файлы из локалки?) с возможностью запускать любые файлы). упомянутая Запись на CD как раз и позволит старое железо использовать просто как отдельно стоящий проигрыватель. Появится красивая музыка, хлынет народ, появятся возможности доработать идею до создания своей "не повернувшейся задом" к мультимедиа операционки и всяких там к ней виртуальных машин тоже, не повернувшихся задом. Может повторюсь , но я вам предлагаю не замахиваться на большое, а просто стараться привлеч больше людей! Создавая то, что под виндой явой и флашем не прет. Наверно только тут сразу надо взять на вооружение 6-ти, а лучше ещё больше сколько только возможно на массовых сценических площадках и кинотеатрах, канальные системы звука. Вот это ваша ниша! А про реанимацию старого железа это я так - подвернулось. Упор может быть только на эффекты, потому что я понял , что вы по своему восприятию музыки не эксперт - поэтому можете только предоставлять тем, кто знает, что народ будет Хавать, эксклюзивные инструменты и (может и ничего не надо кроме них) библиотеки звуков (с возможностью до непрекращения узнаваемости менять их параметры).
С наступающим Новым Годом и успехов. S /c уважением Ё!
Буду благодарен за код Который можно ввести в отладчик при винде Debug и получить, коротенький файлик с демонстрацией возможности графики. Т.е. хочу в ассемблере рисовать или звук делать. А самому уж слишко тяжко пройти эти все пробы и ошибки-хочется просто подглядеть.

[NightRadio]

По поводу предыдущего поста. Фразы типа "поезд ушел", "все что можно было придумать, уже придумано" - не для нас :)
Загрузочные CD - довольно интересно, но это уже отдельная тема, не очень пересекающаяся с языками.
Сейчас у меня уже почти готов план WarmCode, в начале 2009 года планирую приступить к реализации.
WarmCode будет состоять из нескольких уровней:
4. Языки высокого уровня. Си, Pixilang3 и т.п.
3. Исходный код проги в виде "деревьев" (деревья генерируются на уровне 4).
2. Промежуточный уровень. Оптимизация деревьев, преобразование в формат, близкий к машинному коду и опять оптимизация.
1. Генерация машинного кода для выбранного процессора в выбранном формате (EXE-шник, библиотека, бинарник).
Все вместе напоминает чем-то GCC и LLVM, но будет более модульным и легко-портируемым.
Остальные подробности скоро... =)

[Zuf]

Ждем с нетерпением )

[intre]

Круто =))) То есть Pixi 3 будет встроен в эту штуковину?