Портативный .NET
07.11.2006 23:05:53Что-то все-таки тухленько все вокруг разработки Portable.NET. Как выяснилось, главный разработчик покинул проект, и нонче остались в нем только сочувствующие, работающие по старой памяти над своими делами и те, кто реально использует Portable.NET. Первые со вторыми работают над тем, чего больше нравится и очень неспеша, а вторые исправляют баги, поскольку им надо, чтобы работало. Четко сформулированного вектора развития, опять-таки, нет.
Как результат, сторонние патчи рассматриваются ужасно долго, а активность стремится к нулю. Что печально.
А с моей стороны все совсем печально, поскольку хотелось бы увидеть внятную реакцию на свои патчи (в стиле «а вот это низзя» или «круто, cvs commit!»), по результатам которой корректировать свои действия. Размышляю над ужасным — копипастаньем нужного мне хозяйства Portable.NET в свой проект (все равно рано или поздно придется это делать, ибо специфика) и дальнейшей работой в полном отвязе от того, что делается с Portable.NET.
Что еще паршиво, так это модемная связь, невозможно постояно сидеть в IRC и помаленьку пинать всех, кого удастся… Что характерно, стоило выползти и таки застать хоть кого-то вживых, так сразу кончилась модемная карточка. /me очень зол…
10.11.2006 01:18:32
Вы наверное пытались соединиться с #dotgnu на freenode.net, а это irc коммунити DotGNU.
Вообще, DotGNU — это мета-проект, в него входят pgpGroupWare, Portable.NET и DGEE. Например, pgpGroupWare имеет сайт http://www.phpgroupware.org/ и рабочий irc: #phpgroupware.
Для Portable.NET irc должен быть #portable.net, но #dotgnu его очень не признают.
Я сам работаю на #portable.net.
Вообще, irc требует много времени, поэтому имеет смысл активнее использать емайл. В конце концов Линус Торвальдс не пользовался irc!.
Расскажу подробнее о Portable.NET, краткий обзор.
Portable.NET состоит из следующих частей:
1. компилятор — cscc;
компилятор C#;
компилятор C;
2. Библиотеки для среды выполнения pnetlib.
3. Адаптация библиотек, созданных для среды исполнения Mono от корпорации Novell , для среды выполнения Portable.NET ml-pnet
2. среда исполнения для Common Language Runtime и ECMA-335 — Portable.NET:
a) включает интерпретатор;
b) анроллер (промежуточный вариант можду интерпретаторам и простым компилятором времени исполнения, так некоторый кусочки кода для .NET-машины компилируются);
c) компилятор времени исполнения — разработан в рамках Южного Лета кода ( http://community.livejournal.com/ru_mono/18353.html ) для корпорации Trumpf ( http://trumpf.com );
Все три варианта среды исполнения связаны конепцией использования «кодеров». Существует некоторый общий парсер в файлах /pnet/engine/verify_*.c. Данные парсер вызывает функции стандартного API. Конкретная реализация данного API — вариант среды выполнения. Например, для компилятора времени выполнения реализация данного API располагается в файлах /pnet/engine/jitc_*.c. Кодер — это конкретный вариант парсера .NET dll и exe файлов. Статья о приципе работы кодеров на примере его примения для разработки интерпетатора и анроллера: http://www.southern-storm.com.au/download/pnet-engine.pdf
Каждый из вариантов имеет свои достоинтсва и недостатки.
Компилятор времени выполнения — новый проект. Цель которого разработать хороший компилятор времени выполнения, в отличие от той халтуры от Novell под названием JIT Mono.
4. Библиотека libJIT ( http://www.southern-storm.com.au/doc/libjit/libjit_toc.html ) — библиотека для разработки компиляторов времени исполнения от Southern-Storm. Есть варианты для x86, некоторый код для Alpha DE, который разработан в рамках Google Лето Кода 2006 Томасом Кортом (его блог на http://mediumbagel.org/nucleus/ ). Есть большая часть кода для ARM.
10.11.2006 10:01:33
Спасибо, Кирилл.
Я действительно пытался общаться в #dotgnu, по крайней мере Клауса там можно застать. Он даже сказал, что просматривает мои замечательные патчи, но дальнейшей реакции так и не последовало. Я сам значительно больше привык к почтовому сообщению, но когда тишина в эфире, приходится искать другие пути взаимодействия, к тому же, судя по архивам pnet-developers@dotgnu.org, почта тут никогда особо большим почетом не пользовалась.
Насчет интерпретаторов/компиляторов я уже вроде как разобрался, вчера даже получил первую сборку, которая хоть еще и без библиотеки (pnetlib), но уже как-то влазит в мои ограничения. Мне, в принципе, нужен простейший интерпретатор с минимальными размерами. В Portable.NET, однако, интерпретатор навороченный (в хорошем смысле), я читал pnet-engine.pdf, довольно интересно. Еще интересно, как он сравним с современными версиями JIT-компилятора Mono и JIT-ом Portable.NET.
Кстати, что так плохо с JIT Mono? У меня была мысль одно время взять Mono в качестве основы, но там, во-первых, полностью отказались от поддержки интерпретатора (в пользу того самого JIT), а во-вторых, все завязано на Glib. Да еще и код с отступами в два пробела, работать невозможно в принципе… 🙂
В конечном счете мне PNet надо поднять на голом железе, то есть без операционки, поэтому я уже, собственно, приготовился к тому, что придется брать из него необходимые куски и создавать вокруг этого свой проект. Но пока все-таки работаю над оригиналом, он достаточно гибок, чтобы без напряга выдерживать мои издевательства… 🙂
10.11.2006 16:14:56
Антон, JIT в Mono есть, но какой-то он медленный очень по сравнению с Microsoft .NET. Он совершенно не стоит той шумихы, которой над ним подняли. Ну нет там ничего особенного.
Поднять на голом железе часть возможностей, предоставляемых .NET, думаю, возможно. Но здесь надо понимать, что .NET — это в действительности и есть множество определённых возможностей, в том смысле, что в нём обеспечивается реализация/использование некоторых очень удобных, но совершенно независимых концепций: арифметические операции, условные переходы, динамическая сборк мусора, нити, делегаты, удобный вызов функций ОС. Каждый из этих пунктов обеспецивает расширение множества возможностей, которыми можно пользоваться, скажем в С#. Так, например, скомпилировать C# программу для использования на голом железе, которая использует только арифметический операции и условные переходы возможно. Поскольку, последовательность арифметических операций и условных переходов для выполнения на процессоре достаточно интуитивно понятно как реализовать. Процессор непосредственно работает с этими элементами. С остальными возможностями сложнее, их реализации зависят от ОС. Они более абстактны от задач, которые непосредственно решает процессор. Например, сборка мусора использует библиотеку сборщик-мусора Hans-Boehm, а для вывода текста в Console.WriteLine используется в конечно счёте вывод на консоль. Причём эти замечания относятся ко всем существующим средам Microsoft.NET, Portable.NET и Mono, они в большой степени зависимы от возможностей, реализуемых операционной системой.
Есть специальные варианты среды исполнения, например, gcc-cil http://www.dcl.hpi.uni-potsdam.de/papers/papers/loewis_gcc.pdf и .NET micro http://www.aboutnetmf.com/entry.asp. Они реализуют концепцию реализацию подмножества озможностей. Но таких возможстей оказывается не так много.
Есть следующая документация о переносе интерпретатора Portable.NET на встраиваемые системы: http://www.southern-storm.com.au/doc/embedded.html , но думаю надо идти от кода компилятора времени выполнения и библиотеки libjit.
Предполагаю, что реально возможный вариант создания среды без использования операционной системы, идти от компилятора времени выполнения и использовать подмножество .NET/C#, где реализуется арифметика и условные переходы. В других случая, при использании более сложных возможностей .NET придётся использовать или реализовывать в конечно счёте ту или инную ОС (даже если очень специализированную). И это нормальная практика.
Приведу пример: http://pastebin.ca/244956 ,
здесь $Synthetic.$164..ctor. Такие программы использовать без ОС — это относительно реально. Но если использовать большее число возможностей, код будет становиться более ОС зависимым. В действительности, так работают, и C компиляторы.
10.11.2006 16:51:08
/me подозрительно поглядывает по сторонам. Где же спрятался Антон?.. 🙂
OK, может быть. Таких тестов проводить не имею возможности. 🙂
Вижу впервые, интересная штука.
По-любому не по пути. 🙂
Я бы рад, да боюсь, что JIT у меня не влезет в ограничения (имеется внутренний флэш чипа на 256 Кб и 144 Кб памяти). Он и сам по себе сложнее, и памяти при выполнении кушает много. Пока что предполагается использование интерпретатора.
Моя задача состоит в поддержке ядерного профиля ECMA. Виртуальная машина сама по себе не сильно сложна, «интереснее» все становится как только речь начинает идти о библиотеках.
А в конечном счете, среда исполнения Portable.NET и станет здесь своего рода операционной системой. Поддерживающей исключительно .NET приложения.
10.11.2006 16:58:09
Да, Роман 🙂
Я понял идею. Это действительно интересно.
10.11.2006 17:11:54
Роман, в действительности, библиотеки .NET очень интенсивно используют вызовы функций ОС — это так называемые внутренние «internal» вызовы. Вместить среду исполнения в объем порядка 256kb — это антиреально. Но нет причин почему, программы использующие подмножество возможностей предоставляемых .NET нельзя компилировать в статические файлы, как в примере! Это как раз и есть подход gcc-cil и .NET micro. Это только требует времени, например, для этотого нужно доработать поддержку записи в исполнительные файлы. В libjit — это ELF. 50% кода уже есть. Другой вариант, можно просто подавать код на ассемблере, как в примере, на вход в gasm и получать исполнительный файл.
10.11.2006 18:04:29
…а придется. 🙂
Я уверен в том, что это реально. В конце концов, существует ведь реализация виртуальной машины Java в 8 Кб! На сегодня у меня есть сборка pnet, весящая 230 Кб. Естественно, это без библиотеки pnetlib еще, но это и с учетом довольно увесистой библиотеки C (той самой newlib), которая в текущем ее виде мне и не нужна. Я рассчитываю выйти на отметку в районе 100-150 Кб для среды исполнения.
Я согласен, что этот подход имеет некоторые преимущества в ограниченных условиях. Но у меня другая задача. 🙂
10.11.2006 18:31:55
Но ведь это учёт объема без ОС ?
10.11.2006 19:01:00
Конечно. На данном этапе это сборки, которые в принципе не будут работать. Однако, в pnet и в newlib есть что срезать для того, чтобы уложиться в заданный объем с учетом расширения функциональностью ОС.
Кстати, пример с Java приводился для голого железа: http://www.osrc.info/news.php?item.3077