[X] Помощник

[mamaich]

Уверен, что не только я думал о том, как бы так исхитриться, и получить возможность компиляции старых исходников на си под winPhone. Пусть с некоторой потерей в производительности - главное тут, чтобы работало, и чтобы не требовалось вносить изменения в исходниках.
В голову пришла простая идея - а не сделать ли компилятор Си в байткод (хотя бы в тот же х86 или арм), а потом исполнять данный байткод? Конечно, страдает производительность, но зато универсально.
Погуглив, оказалось, что подобная идея пришла не только мне, и уже даже реализована. Но для явы, а не .NET - emscripten. Совершенно не вникал в подробности их реализации (не люблю яву), так что данную идею реализовал по-своему, тоже взяв за основу LLVM:
Си-код компилируется в llvm байткод с помощью clang (это полноценный С/С++ компилятор, совместимый по ключам с gcc). Байткод - декомпилируется в C#-конструкции, выполняющие соответствующие команды. Функции LLVM = функции на C#. Все указатели - это индексы в массиве. Все регистры (а их в LLVM бесконечное количество) - локальные переменные. В LLVM нет никаких флагов процессора, то есть не требуется придумывать как бы по-оптимальнее их сэмулировать.
В моей реализации поддерживаются указатели на данные и на функции, структуры, юнионы, плавающая точка. Есть зачаточная libc (взял реализацию из klibc). Не работает setjmp/longjmp, извращения типа goto (*адрес), С++ исключения. Если первое и второе реализовывать точно не буду, то об исключениях - думаю.

Как первый тест идеи - собрал диггер не внеся в его исходники ни байта исправлений. Для его работы собрал SDL (вот в нем пришлось добавить свой код), и zlib (тоже без изменений в исходниках).

Архив приложен. Там готовый XAP файл + исходники, для желающих посмотреть во что превращается сишный код после трансляции в C#.
В SDL пока не реализован звук, систему реакции на кнопки надо переделать на более удобную. Сейчас управление сделано так: экран разбит на сетку 5х3 клеток. При тыканьи в каждую из данных клеток эмулируется нажатие одной из кнопок - стрелки, выстрел, выход. Какие кнопки где именно - найдете сами.

Сейчас вот думаю, что попробовать следующим собрать. Досбокс (тормозить, правда, будет), или на scummVM посмотреть?

Транслятор LLVM->C# не выкладываю. Пока что в нем есть простор для доделок и оптимизаций, да и базирован он на LLVM 3.1, которая еще находится в стадии бэты. Вот выйдет релиз 3.1, тогда посмотрим. Сырцы транслятора выкладывать не планирую.

Сообщение отредактировал mamaich - 06.12.2011, 10:17

Прикрепленные файлы
digger_sdl_src.zip ( 1.17 МБ )Кол-во скачиваний: 21

[S_K]

digger порадовал однозначно, даже с текущим управлением =)
Идея тоже.

[Lolmaker]

mamaich,
Идея конечно отличная

[bozox]

Интересно. С нетерпением жду поглядеть на инструментарий...

[mamaich]

в НГ праздники планирую привести тулкит в более-менее законченный вид.

Для теста хочу досбокс собрать. Не думаю, что скорость работы будет выше 80286 на 8 мгц, тк оптимизацией и доведением до ума заниматься лень.
Так что это скорее будет proof of concept и проверка всей идеи на реальном проекте. Если досбокс заработает - выложу тулкит на публику.

[wlcool]

а alreader2 можно так скомпилить?
досбокс это конечно хорошо, но практической пользы не вижу. лучше уж эмулятор gba/ндс какой-нить, опенсорс вроде как раз sdl любят

[mamaich]

а alreader2 можно так скомпилить?

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

[CodeDaemon]

Автор у вас получается такая цепочка C++ ==> LLVM == IL(C#).
Те в итоге получаете тоже самое что получите просто используя C#.

В чем смысл тогда писать на С++ который через мясорубку превращается в .NET?

[bozox]

Смысл не в том, чтоб на С++ писать (с нуля), а в том, чтоб существующий код (которого много) хоть как-то под WP7 подогнать, на C# полностью не переписывая.

[mamaich]

bozox правильно сказал. Тот же флеш плеер никто на C# переписывать не будет.
Кроме того, подобная конструкция будет успешно проходить валидацию приложений на стороне МСа, в отличие от приложений, использующих interop.

P.S. Наткнулся на проблему в студии 2010 - студии иногда не хватает памяти при компиляции >40-мегабайтных C# файлов, приходится разбивать сгенерированный код на части

[S_K]

Наткнулся на проблему в студии 2010 - студии иногда не хватает памяти при компиляции >40-мегабайтных C# файлов, приходится разбивать сгенерированный код на части

а в MSFT отослал? =)

[wlcool]

а не приходила идея сразу в IL конвертить?

[bozox]

Там нетривиальная трансляция. MSIL - стековая машина, LLVM - регистровая.

[mamaich]

На самом деле я гуглом находил проект LLVM->MSIL, но у нас все много запущеннее - разрешены только safe конструкции, то есть имеются искусственные ограничения.

Попробовал на LLVM собрать более-менее большие проекты, тот же DosBox, ScummVM - наткнулся на баги текущей версии LLVM при компиляции в байткод. Поэтому идея о создании тулзы, позволяющей универсально портировать большие проекты С++ -> C# - не оправдалась (а мелкие проекты можно и вручную переписать).
В текущей реализации транслируется только С код (максимум - С++ конструкции без RTTI и исключений, и с урезанным из-за этого STLPort), да и скорость работы итогового кода - весьма низкая. Флеш плеер будет тормозить, DivX видео тоже не посмотришь, даже банальная демка "огонь" дает 2 FPS в 800х480 на девайсе с гигагерцовым процессором

Сырцы приаттачены к посту. На случай если кто-то решит понаступать на те же грабли - распаковать поверх сырца CBackend в LLVMе 3.1. При компиляции использовать ключи как для CBackend-а. За основу транслятора, как уже понятно, использован C Backend. Я когда брался - не знал о его ограниченности, и о том, что сами авторы отказались от его развития.
Далее я проектом заниматься не буду - наткнулся на концептуальные баги C Backend, в частности его надо полностью переделывать для поддержки >64-битных регистров (оптимизатор LLVM очень любит их использовать), поэтому время было потрачено практически впустую (за исключением приобретенного опыта, конечно).

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

Я бы делал проще. "Придумал" свой 32-битный VM-байткод, с организацией памяти как массив DWORDов (а не байтов как сейчас, это даст прирост в скорости на АРМ в большинстве случаев), без процессорных флагов, и транслировал бы LLVM->этот байткод (такой транслятор написать можно довольно быстро, туториалы есть на сайте LLVM).
А на C# написал бы динамический транслятор этого байткода в MSIL "на лету" (хотя надо проверить, дают ли нам такое делать на WP7). Или статический транслятор в C# код. Но у статического подхода есть дополнительная проблема - для больших программ типа ScummVM, на выходе получаются настолько большие файлы, что итоговая DLLка банально не помещается в память на девайсе.

Сообщение отредактировал mamaich - 24.01.2012, 04:58

Прикрепленные файлы
CsBackend.zip ( 133.64 КБ )Кол-во скачиваний: 2

[bozox]

Вообще-то звуки на тему родного кода со стороны MS доносятся; петиция вот Under review, и сотрудники MS там время от времени в ленте отписываются.

А что цифровая подпись? Под MS Marketplace 6.5 компилировались же как-то, и ничё. А кто хочет side-loading, тем ChevronWP7 в зубы.

Сообщение отредактировал bozox - 24.01.2012, 05:11

[mamaich]

А что цифровая подпись? Под MS Marketplace 6.5 компилировались же как-то, и ничё. А кто хочет side-loading, тем ChevronWP7 в зубы.

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

У подписи есть одна проблема. Чтобы подписали твой WP7 XAP сейчас - тебе надо отправить его мелким на валидацию. И если XAP им "не понравится" (юзает interop, например) - подписи не получишь.

Цитата, просто для информации:
"WOA platforms will require that all desktop binary images be signed with a trusted Microsoft certificate. Any unsigned code will fail to load ... This ... does not cover Metro Style applications for which there is a separately documented signing requirement and developer licensing"
Судя по всему, текущая ситуация останется и в WP8 для метрошных приложений. А вот каковы требования по подписыванию нативных бинарников - пока сведений нет.
Еще цитаты:
"Windows Phone "Apollo" brings together platform parity with Windows 8, experience parity with Windows Phone "Mango", and a set of new features and functionality developed for Windows Phone "Apollo".

Platform parity means that the phone OS is now based on the Windows NT kernel instead of the Windows CE kernel. Windows Phone "Apollo" uses the Core System from Windows 8, which is a minimal Windows system that boots, manages its hardware and resources, authenticates and communicates on a network, and can be managed at a basic level.
....
The final significant changes of note are the adoption of ESENT, also known as Jet, for the database engine, and the managed-code runtime. Rather than using the .NET Compact Framework from Windows Phone 7, Windows Phone ”Apollo” uses the Core CLR produced by the Developer Division at Microsoft."
То есть, по крайней мере .NET фреймворк станет наконец полноценным. Но, опять же, ни слова про снятие ограничений на только safe код.

Сообщение отредактировал mamaich - 24.01.2012, 12:17

[bozox]

Я из своего поста удалил про аполло

NDA, что ли?

Чтобы подписали твой WP7 XAP сейчас - тебе надо отправить его мелким на валидацию. И если XAP им "не понравится" (юзает interop, например) - подписи не получишь.

Вы, коллега, под iOS никогда не писали? Подобная анальная поза - давно уже норма в индустрии мобильного софта. Windows Mobile было приятное исключение; больше не будет.

.NET фреймворк станет наконец полноценным.

А вот это хорошо. Давно б так.

[mamaich]

NDA, что ли?

Не, NDA не подписывал, но файлы обещал не выкладывать. Просто не по теме было, но раз уж начал - еще про аполло:
"Only SDHC cards formatted as FAT or exFAT are supported. If the card is unformatted or contains an unsupported format, such as NTFS, the SD card will be formatted according to the SD specification if the user accepts the format prompt. This means that SDHC cards (cards less than or equal to 32GB) will be formatted as FAT" но хотя бы радует: "The internal user store will not have this limitation since it is formatted as NTFS".
На самом деле - полнейший маразм не давать форматировать SD карту в NTFS, при условии что сама OS его поддерживает.

а вот это вообще интересно. Правда не факт что в релизе не уберут:
"Texus Shell (TShell) is a tool that allows you to interact with Windows Phone "Apollo" phones via a Windows PowerShell command prompt. You can copy files to the phone, execute processes, attach a debugger, run commands using the phone's command interpreter, and run test content stored on WTT test servers"
типа "adb shell" в андроиде

Про сенсоры
"The Windows Phone "Apollo" release ports the ambient light, proximity, magnetometer, compass, and gyroscope sensors from Windows Phone "Mango". It also incorporates the accelerometer, which was a standalone implementation in the previous OS version", еще поддержка NFC обязательно будет.

кстати
"You can use Hyper-V to test x86 builds of the phone OS"
Глядя на то, с какой регулярностью в сети оказываются новые билды настольной вын8, ждем когда у кого-нибудь утечет VHDшник с х86 аполлой

[bozox]

http://arstechnica.com/microsoft/news/2012...tiple-cores.ars

Пишут, что в WP8 Apollo будет родной код. Правда, это leak, а не официальный анонс.

[semack]

Вот 2 вещи, которы я хотел бы собрать для винтелефона

итереснейшая статья, в конце ссылла на сорцы на github
http://fabiensanglard.net/anotherWorld_code_review/index.php

порт на ps2
http://www.megidish.net/flashback/

или подождать?
http://news.techlabs.by/16_236657.html

Сообщение отредактировал semack - 05.02.2012, 12:00