> Language: HQ9plus
> Status: Works and is mostly complete.

Шутку понял, смешно. :)

______
/\ __ \
\ \ \/\ \ __ __ ______ ______ (P)erl6
\ \ __//\ \/\ \/\ __ \/\ ___\ (U)ser's
\ \ \/ \ \ \_\ \ \ \/\ \ \___ \ (G)olfing
\ \__\ \ \____/\ \____ \/\_____\ (S)ystem
\/__/ \/___/ \/___/\ \/____/
/\____/ Version: 6.2.12
\/___/ Copyright 2005-2006, The Pugs Contributors
--------------------------------------------------------------------
Web: http://pugscode.org/ Email: perl6-compiler@perl.org

Welcome to Pugs -- Perl6 User's Golfing System
Type :h for help.

Loading Prelude... done.



6 перл от пятого далеко ушел, такое впечатление после прочтения книги
есть новые операторы: say, connect и др - они более универсальны и давно напрашивались..

Помнится, был один перец, который взял как тему диссертации своей -- создание компилятора C в Parrot (прикрутить Parrot к gcc хотел). Так и не слышно ничего. Наверное, не защитил. :)

жду с нетерпением, когда оно во что-нидь толковое материализуется. полгода назад книгу купил о перле6 и парроте: задумка инетересная, не менее интересно, с какой скоростью это всё будет крутиться :)

Далеко не так хороша поддержка языков. Например о ruby там написано, что он unmaintained и removed from trunk.

не всё ведь в Руби упёрлось

И питон оно плохо умеет, потому что в Parrot'е до сих пор нет классов. :) Который год дождаться не могу, блин, пока они там появятся.

Бесспорно, хорошая задумка.. Посмотрим, что из этого выйдет на практике..

Попка дурак.

Спорно что это хорошая задумка. Зачем нам ещё одна Java Virtual Machine и DotNet Framework? Не исключено, конечно, что Parrot окажется более удачной реализацией чем JVM и DF, так что пусть люди делают, если им нравится. Но, повторюсь, то что это хорошая задумка спорно.

к сожалению в реальные сроки "ниасилили", ждали еще в 2002-м, особенно те, кто не хочет работать с моно или жабой.

> Спорно что это хорошая задумка. Зачем нам ещё одна Java Virtual Machine и DotNet Framework?

Why your own virtual machine? Why not compile to JVM/.NET? Those VMs are designed for statically typed languages. That's fine, since Java, C#, and lots of other languages are statically typed. Perl isn't. For a variety of reasons, it means that Perl would run more slowly there than on an interpreter geared towards dynamic languages.

The .NET VM didn't even exist when we started development, or at least we didn't know about it when we were working on the design. We do now, though it's still not suitable.

http://www.parrotcode.org/faq/#Why_your_own_virtual_machine%3F_Why_not_compil...

Просветите анонимуса, зачем оно нужно и в какой области народного хоз-ва оно применяемо?

>Бесспорно, хорошая задумка.. Посмотрим, что из этого выйдет на практике..

Java! Но потом:))

у него хоть jit есть?

А нету. Ясно:)

> И питон оно плохо умеет, потому что в Parrot'е до сих пор нет классов. :) Который год дождаться не могу, блин, пока они там появятся.

Долго дожидаться придётся. Или это такая скрытая шутка юмора? Parrot'у (как регистровому ассемблеру) только классов для полного счастья не хватает...

Попка не дурак.

Понял, ero-sennin. Спасибо за объяснение.

пошел шестой год разработки perl6.. ню-ню

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

Вобше-то JVM/.NET по другому утроена насколько я знаю по сравнению с парротом.

зря грохнули мессагу про D. там и кроме яиц кое-что было.

про D -- а он уже открытый? и даже работает? и на линухе он не через gcc?

> у него хоть jit есть? > А нету. Ясно:)

Вызывающе неверная информация, JIT есть. Опция -j

Шутка старая но всё равно смешная:
http://n0x.org/browse/images/perl6.jpg

>Долго дожидаться придётся. Или это такая скрытая шутка юмора? Parrot'у (как регистровому ассемблеру) только классов для полного счастья не хватает...

Извращенцы... Делать VM регистровой! Чем им стек не угодил?

> Извращенцы... Делать VM регистровой! Чем им стек не угодил?

когда parrot начинали писать это была главная фича..

> Шутка старая но всё равно смешная:

lol! я вот раньше не видел, спасибо.

>Вызывающе неверная информация, JIT есть

ТАм в факе написано что он что есть что нет - разница несущественна. Значит нету.

>когда parrot начинали писать это была главная фича..

чето я не понимаю. Стековая машинка позваоляет переукинуть регистровые оптимизации на vm. Чем лучше VM - тем лучше работает все. А тут все вернали взад писателю компиляторов - сначала он будет долиться с рапределением регистров и оптимизациями, а потом что - паррот будет передалбливать в зависимости от нативной платформы все поновому?

Или он вообще ничего не делает, а интерпретирует свой ассемблер "покомандно"? Тада неудивительно что jit что есть что нету..

> Извращенцы... Делать VM регистровой! Чем им стек не угодил?

Быстродействием. Будь моя воля, вообще-бы безрегистровую делал (только для временного хранения), на память-память. Интерпритатору - всё равно, а jit сам лучше решит в какой конкректный машинный код преобразовывать.

P.S. Насчёт "моей воли", просто н-ное время назад сам подумывал о создании VM, но проанализировав всё пришёл к выводу, что реализовать задуманное в одиночку непоъёмно. С тех пор внимательно слежу за parrot. ;-)

> Или он вообще ничего не делает, а интерпретирует свой ассемблер "покомандно"? Тада неудивительно что jit что есть что нету..

См. документы с сайта.

http://www.parrotcode.ks.ua/docs/ru/overview.pod.html

http://www.parrotcode.ks.ua/docs/ru/faq.pod.html

http://www.parrotcode.ks.ua/docs/ru/jit.pod.html

Но это старый и не очень хороший перевод. Лучше найти оригиналы.

> Извращенцы... Делать VM регистровой! Чем им стек не угодил?

Достоинств, как минимум, два:
1) легче переводить эффективный машинные код, ведь все мейнстрим-процессоры суть - регистровые машины.
2) скорость, как в случае интерпретируемого байт-кода, так и в случае сгенерированного машинного кода.

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

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

Стековая машина:
next:
...
load(a)
incref(top)
t0 = pop()
t1 = pop()
t2 = t0 + t1
decref(t0)
decref(t1)
push(t2)
...
goto next

Регистровая машина:
R1 = a
incref(R1)
...
next:
...
R2 = R0 + R1
decref(R1) # если R1 больше не нужен
...
goto next
decref(R1)

Ну вот, при грамотной реализации ускорение должно быть налицо! :)

прошу прощения за очепятки, править не дает :(

в цикле должно быть ... decref(R0) # если R0 больше не нужен ...

> но вот ожидать чего-то юзабельного уже не приходится.

а что, и текуший Perl не юзабелен? а то они там тоже отметились :)

Ну вот, снова Гвидо на торт тратится :)

> зря грохнули мессагу про D. там и кроме яиц кое-что было.

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

> про D -- а он уже открытый?

Есть открытая реализация GDC, есть закрытая. Так или иначе, глобальная тенденция такова, что сидение на собственных исходниках чревато пролётом.

> и даже работает?

Раз пишут, значит работает? :) В любом случае, вам никто не запрещает БЕСПЛАТНО скачать полный дистр D и программить.

> и на линухе он не через gcc?

Нет, у него своя компилялка. Хотя корни растут да, из c++.

Вообще, поинтересуйтесь вопросом, весьма перспективный язык. С ГУЯми у него конечно бардачок, но в принципе выбор есть. БД поддерживает, сокеты... Для большинства юзерских приблуд - за глаза.

http://www.parrotcode.ks.ua/docs/ru/jit.pod.html

Ну вот прочитал - и не понимаю нафига это нужно

set I0,8
set I2,I0
print I2


Если jit все равно переколбасит это в конченом итоге до вызова через стек:

0x817de01 <jit_func+49>: push $0x81774c0
0x817de06 <jit_func+54>: call 0x804be00 <Parrot_print_i>

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

2 + 3 + 4 + 5

то вместо (псевдо)

push 2
push 3
push 4
push 5
add
add
add

надо будет иметь что-то типа (тоже псевдо) (если там конечно регистров не неогранниченное колличество)

set I1,2
set I2,3
add I1,I2
set I1,I0
set I2,3
add I1,I2
set I1,I0
set.......

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

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

Или я что-то существенное незаметил?

>если используется сборка мусора методом подсчета ссылок

Не используется (see faq).

>Ну вот, при грамотной реализации ускорение должно быть налицо! :)

Это если vm-регистры замапить на реальные. Но такого там нет. Все равно там все загоняется в стек и зовется джитная функция.

И стековый вариант тоже можно оптимизировать jit на регистровый в нативе. Тут уж от умности jit все зависит.

s/стековая машина/регистровая машина/

Плохой пример ты привёл, так как "2 + 3 + 4 + 5" будет подсчитано ещё на этапе компиляции/парсинга. Но предположим, там переменные. Всё равно, если тебе лень, до низкого уровня спускаться не надо, можно просто написать:

I0 = 2 + 3 + 4 + 5

И parrot сам переобразует в нечто типа:

I0 = 2
I0 += 3
I0 += 4
I0 += 5

Что идентично альтернативной записи

set I0, 2
add I0, 3
add I0, 4
add I0, 5

Или добавит регистр в случае с переменными, так же как он даёт возможность автоматически работать со строками.

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

I$0 = 2

>Что идентично альтернативной записи

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

>А вообще, лучше в своих подпрограммах использоват виртуальные номера регистров, перекладывая на parrot реальное выделение.

Тогда отличие от стековвой машины становиться совсем маленьким. Нафига вообще тогда этим париться? int-регистры, float-регистры.... - представь только насколько усложничться кодогенератор для арифметического выражения в котором несколько типов заюзано по сравнению со стековым, который может буквально "по скобкам" все перевести в стековый ассемблер и не париться, оставив все jitу, который будет в курсе как это разложить на одному ему известное количество физических регистров и что с этим сделать.

> Возьми выражение, обложи его скобками по самое нихачу (или любыми вложенными блоками) и увидишь как регистры кончатся.

Если кончатся, то parrot будет использовать другие средства, как память (глобальные данные или локальный стек). Но пока не кончились - быстрота гарантирована. Просто в регистровой виртуальной машине появляются дополнительные возможности для оптимизации (когда разработчику алгоритма известно заранее время жизни тех или иных данный). То есть появляется возможность кросс-процедурной оптимизации на этапе программирования (регистр 5 задаётся глобальным и используется для передачи информации между процедурами). При этом ничего по сравнению с стековой ВМ не теряется. Что же здесь плохого?..

>Что же здесь плохого?..

Ну - то что это другой уровень. Если писать на чистом парроте - то да такое шаманство можно творить. А если писать компилятор? Шаманства будет значительно меньше, но самое плохое что у джита на сей счет будет своя точка зрения - как там даже в примерах - что толку ганять значения по регистрам, если все равно jit его запихнул в стек и дернул свой натив? В чистом интерпретаторе да - будет хорошо. Но джит то менее эффективен получается. Плюс усложнение работы каждого компилятора.

> ГУЯми у него конечно бардачок, но в принципе выбор есть. БД поддерживает, сокеты...

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

К стати - вот почитал я побольше про егойный ассемблер - такое впечатление что цель разработчиков паррота не vm написать, а крутой ассемблер. Со всеми его макрами, циклами и прочей высокоуровневой бойдой, которая в intermediate language и нафик не нужна.

Ты решил портировать дополнительный язык программирования, и можешь запросто это сделать без всех вкусностей parrot? Или ты за других разработчиков решил говорить? :)