Мое почтение, коллеги

На чем сейчас можно писать приложения с возможностью оптимизации под процессоры XScale (с использованием WMMX) для платформы WinCE? Для моих приложений (обработка видео) использование MMX критично. Использую MSVS 2008, у нее, в принципе, есть ключ /Qxscale, но глядя на получающийся ассемблерный листинг, я вижу, что MMX он не использует, в тех местах, где оно просится. Я бы, может, попытался критичные куски вручную наваять, так ассемблера для ARM в ней нет вообще.
Поставил, для пробы, MSVS 2010, так там программирование для Smart Devices отсутствует как класс. Как быть?

И ассемблерные вставки делать нельзя ? Не верю. Читайте документацию. Такого просто не может быть ...

Ассемблерные вставки делать можно, для x86, их обрабатывает MASM, а ARM ассемблера там нет. Не знаю, может бывают варианты MSVS, имеющие в составе ассемблер для ARM, но в описании я не нашел. Потому, собс-но, и спрашиваю.

Вообще, ситуация какая-то непонятная. В MSVS 2010 поддержка ARM отсутствует полностью, пишут, что вынесли все в продукт Windows Phone SDK. Поставил, для пробы, этот Windows Phone, так там вообще только бейсик и C#. На чем сам Микрософт драйвера пишет, не на бейсике же? А ничего другого у Микрософта не нашел.

Прочел, что нужная мне поддержка есть в Intel C++ Compiler for eMbedded VC++. Правда, вся инфа, что попадалась об этом, довольно-таки старая, ссылки на Intel C++ Compiler версий 7, 9. Поставил, опять же, для пробы, Intel C++ Compiler, но современная версия - 11, и там тоже уже нет поддержки ARM. Искал более ранние версии - нет нигде. Не завалялось ли у кого-нибудь, случайно, Intel C++ Compiler версии 9?

В общем, совершенно непонятно на чем теперь народ под ARMы под Винду пишет.

И еще вопрос у меня, к знающим, если взять какой-нибудь IAR for ARM (про него пишут, что он под XScale оптимизирует), можно там собрать статическую либу, чтобы потом MSVS к своему проекту смог прилинковать? Правда, такой вариант отлаживать будет тяжеловато, но хотя бы так...

Разве Винда под АРМ не труп?

Мы пишем под XScale и WinCE используя Embedded VC, уж не знаю, использует ли оно ММХ, и есть ли вообще ММХ на АРМах? Беглый поиск дал ссылку http://www.microsoft.com/en-us/download/details.aspx?id=4800

Embedded VC не использует MMX, про его встроенный ассемблер не знаю, не проверял, компилирует ли он MMX команды. Это крайний вариант, хотелось бы все же С-компилятор. Опять же, самим Embedded VC пользоваться достаточно неудобно, каменный век. Мне так и не удалось его запустить на Win7-64 (под Вистой еще работал). Пользуюсь только в виртуальной машине.



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

Зачем андроид? Можно и VxWorks, можно и встраиваемый Linux.
Первый если хочется денег заплатить. Второй, если опыт есть и роялти не хочется платить и нужна очень большая гибкость.

P.S. Кстати интересно узнать и какая же ниша у WinCE? Драйверов нету, ГУИ - устаревшее, даже подобия реального времени нету, ресурсов жрёт много, готового софта - почти нету, программистов под втраиваемую винду тоже всё меньше и меньше. Странная штука.

Из того, что мне близко - охранные системы, СКУД, видеонаблюдение, видеорегистраторы (я имею в виду железки, а не сервера сбора данных). Из того, что не близко, но могу предположить - медицинская аппаратура, измерительное оборудование, всякие там осцилографы и энцефалографы, и проч.

Эти применения вообще можно делать на чём угодно. Никаких достоинств WinCE тут не даёт. Это всё более менее массовые продукты. ИМХО тут операционку с более низкой ценой лучше брать. И с бОльшей гибкостью.

Тут ситуация другая - аппаратура малотиражная и более дорогая. Её просто исторически делали на Win. Переделывать получается дороже, чем обновить на что-то более удобное/дешёвое.

ARM ассемблер VS2005 с ключом /Qxscale понимает WMMX инструкции сопроцессора. Могу предположить, что в VS2008 все тоже самое.
Не думаю, что С компилятор будет сам использовать сопроцессор, для этого надо самому вызывать MMX intrinsic функции.
Может быть еще правильнее пользоваться библиотекой IPP из старых версий, поддерживающих XSсale, ежели такую удастся достать.

Не знаю насколько хорошо вы знакомы в WinCE, и стоит ли тут что-то обсуждать.
С драйверами и BSP проблема скорее не в их недостатке, а в их качестве. А скажите где с этим хорошо и задешево ? С другой стороны если под платформу есть добротный BSP, то опыт показывает, что дописать специфичные для встроенного устройства драйвера не большая проблема даже для среднего ембедера. Модель драйверов простая и есть откуда срисовывать, отлаживаться легко.

Ресурсов она ест сопоставимо с системами этого же класса, скорее даже поменьше. Все что легче, оно, увы, и ограничено по функциональности и гибкости.

Про отсутствие подобия реального времени - ИМХО однозначно заблуждение. Особенно в контексте упоминания Lunix. Конечно не QNX и иже сними, но они и стоят радикально других денег. И проблем с ними в части BSP, GUI, middleware, средств разработки и программистами уж точно никак не меньше. Для приложений, где нет требований критической надежности и реакции на микросекундном уровне реал-тайм WinCE будет золотой серединой. Например, для 500МГц ARM латентность прерывания для пользовательской ISR меньше 10мкс, и меньше 100мкс до пользовательского потока, по-моему вполне для разумно организованной системы.

С программистами с одно стороны проще. Для разработки приложений любой, кто пишет под Win32 на студии, почти не заметит разницы. Под уровень сборки образа и BSP сложнее, но и для других систем такие люди товар штучный и еще более дорогой.

Не знаю, что имелось в виду под устаревшим GUI. Исходно там все тот же Win32 GDI. ИМХО был недостаток middleware для рисования красивого и модного GUI, хотя та же QT есть. С появлением Siverlight с блендом должно быть много лучше, сам пока не пробовал, но в шаг в правильную сторону.

Проблема, конечно, куда там дальше микрософт вильнет. Но на данный момент с альтернативами не густо.

Одно время рассматривал возможность запуска WinCE на своём изделии (тоже на XScale). Ознакомился с Platform Builder, собрал систему. На тот момент времени функционал получившейся системы оказался неконкурентоспособен.

BSP для WinCE сейчас отсутствует для 90% чипов с MMU. А на чипах без MMU наверняка не работает вообще.
С 2006 года никакого развития. Только в 2011 году выпустили новую версию. ИМХО последнюю.

Линукс сейчас по этому критерию однозначно лидирует. Производители чипов хотят заполучить огромный рынок на Andriod.

Есть ли какие-нибудь результаты тестирования? Или это предположение?

Программисты под win32 тоже скоро станут редкими.
Основной трэнд - ява. На этой платформе пишет огромное количество взаимозаменяемых программистов "высокого уровня". И не за дорого.

Это и есть жуткое старьё. Делать на "этом" удобный пользовательский интерфейс долго без использования каких - либо тулкитов. А любой вменяемый тулкит может работать практически на любой платформе.

По секрету скажу, что Микрософт решила похоронить сильверлайт как не оправдавший себя проект.

P.S. Искренне удивлён, как вам удалось связываться сразу с несколькими, которые уже "уходят в мир иной":
1. XScale - процессорное ядро на текущий момент поддерживаемое только интелом. Вытесняется по всем фронтам процессорами на базе ядер Cortex-A.
2. WinCE - безнадёжно отставшая ОС. Микрософт прекратит её поддержку в пользу "Windows RT".
3. Silverlight - "..компания Microsoft также фактически отказалась от разработки Silverlight в пользу технологий HTML5, которые будут использоваться в Windows 8. Silverlight 5 был выпущен в конце прошлого года и будет официально поддерживаться до 2021 года, но это будет последним значительным релизом платформы, развитие которой приостановлено. "
4. Win32 API - "Only software written using the Windows Runtime (Metro-style apps) can be used on Windows RT. Developers will not be able to create applications to run on Windows RT using the Win32 APIs" (Надо перевести?)

Да, так и есть, я вроде уже разобрался, спасибо. Сейчас пытаюсь вручную критичные куски кода на MMX переписать. Найти бы где-нибудь толковое описание этих intrinsic функций, или примеры использования. А то в MSDN фактически только прототипы, приходится их с описанием машинных команд сопостовлять, муторно.

Не использовал, посмотрите в Intel Wireless MMX Technology Developer Guide, там есть описание intrinsic.
Попробовал не разбираясь скомпилировать с mmx intrinsic, ругается на выравнивание __m128. Не подскажете, что ему надо?


Ок, значит в теме. Только естественно без MMU не работает. ИМХО для наших приложений (industrial, приборостроение) на данный момент в этом классе конкурирует с embedded Lunix, остальное из другой категории.


Да, развитие замедлилось в последние годы, причем последняя WinCE7 не очень революционная, разве что многоядерность добавили. Только конечно не с 2006, они шестерку активно развивали до 2009. Могут и забросить. Хотя линейку для embedded развивать будут, а значит нужна будет адекватная замена.
Не смотрел последние пару лет где какие BSP выходят, может тренд в сторону линокса и есть. Не назовете какие чипы попали в эти 90%?


Частью сам проверял, часть по чужим системам и слухам. Тут, конечно надо уточнить, что под ресурсами понимаем. Объемы памяти под образ и RAM? Если про производительность, то по каким критериям? Время реакции называл и это не предположения. Есть еще потребление, время загрузки и т.д..



Ну и шарп еще. Тренд действительно туда, насколько это хорошо годится для глубоко встраиваемых систем у меня пока сомнения.


Полностью согласен, без обертки не обойтись, c которой в реальности проблемно. Только у кого лучше? На линоксе будет тот же QT, ну может быть чуть более родной, но не ставший от этого не легче, не резвее. QNX прикрутила флеш. Поэтому и говорю, что силверлайт в шестерке должен быть в тему, даже неважно от его судьбы на PC, поскольку нативный для системы. Не делал на нем ничего, может гладко на было на бумаге. Также как и про глубину оврагов для вменяемого тулкита (какого интересно?) на любой платформе.


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


О чем вы, нету его давно уже у Интела. Он усех кинул и продал мобильную линейку Марвелу, котрый выпустил несколько чипов в развитие. Конечно никуда с мейнстрима Cortex-A никто неуйдет, но это не принципиально, уж тем более для больших осей и управляемого кода.


Вот это посмотрим на чем MS будет встроенный рынок удерживать. Повторюсь, что здесь надо вдолгую играть. И не путать ядро для мобильных платформ и для глубоко встраиваемых приложений. Хорошо, чтоб микрософт это тоже не путала
Толково это объяснено по ссылкеWhy Windows Embedded Compact is here to stay..

Все процессоры с ядрами PowerPC, SPARC, MicroBlaze, Motorola 68000, M32R (Renesas), TMS320C6x.
Это я ещё всякую экзотику не брал типа вымерших AVR32.

Вон на выставке своими глазами видел работающий linux на CortexM4 от Freescale. Время загрузки - около секунды. И крутится демка на QT. Памяти там тоже было совсем мало. WinCE так сможет?

Шарп - да.
Однако отсутствие вменяемых инструментов для каких либо платформ кроме как от микрософт приводит к зависимости и опять таки к отсутствию выбора.
ИМХО на шарп лучше не закладываться.

У Явы, QT, GTK лучше. HTML5 может стать одним из фаворитов в ближайшем будущем. (Посмотрим как всякие ChromeOS, FirefoxOS и WebOS поведут себя на рынке).

На Линуксе можно запустить практически всё: QT, java, GTK. Даже .NET и GDI.

Flash - тоже умирает. Адоб в скором времени перестанет его поддерживать развивать в угоду HTML5. Такие дела =)

Согласен, в эмбеддед приходится долго играть. Для этого надо иметь максимальную независимость от прихотей какой-либо одной компании.
Свернёт МС эмбеддед - по миру идти?
Свернул Атмел AVR32 - по миру идти?
Свернёт Адоб свой Флеш - .... ?

Мое почтение!

А у Вас какая платформа? Как я понимаю, __m128 это SSE2, а его далеко не все платформы поддерживают. У меня __m64, но и с ним засада обнаружилась.

Вот, к примеру, такой код


Посмотрим, во что он компилируется, начиная со строки (!). Релиз, все возможные опции оптимизации выставлены на максимальную скорость, MSVS2008.



Вопрос - зачем строки 50...60? Почему бы сразу не сохранить в нужное место? А так, получается, на одну MMX команду, где достигается какая-то экономия, аж 5 ненужных пересылок с памятью вместо одной. Я помню, в XX веке компиляторы генерировали подобный код, но сейчас, мне кажется, это уже как-то неприлично, компилятор должен оптимизировать это на раз.

Но это даже не главное. А главное - почему команда wstrw, а не wstrd?! Получается, что сохраняются только младшие 32 биты из 64, а в старших битах оказывается мусор. Причем, в данной команде, положим, результат не может выйти за 32 бита, но такой же код генерируется и для всех других функций, в частности, для _mm_unpackel_pu8() и подобных, где уж точно все 64 бита нужны. Везде используется wstrw, только младшие 32 бита.

Что это, баг компилятора!? Слабо верится, почему никто не заметил, ведь ни одна MMX функция не работает. Или я чего-то не понимаю?

Причем, под Win32 тот же код компилируется и работает правильно, проблема только под ARM.

А я то подумал, что что-то пропустил. Это все из другой оперы, объяснять долго. Интересно про линокс на C6x, не знал, спасибо.


Чай на Kinetis uClinux был, ибо где ж там MMU, т.е. чуток что-то попроще. Насчет совсем мало памяти не горячитесь, посмотрите сколько QT занимает, мне в свое время не понравилось. И сколько даже утоптаный uClinux. Не будучи пророком скажу, что стояло на той платке много мегабайт внешней памяти. CE при такой же фунциональности упихнете в похожий объем, если не меньше. Увы нет тут чудес. Секунда красиво, но разбираться надо, что реально грузится. Не отличается линокс особой скоростью загрузки, CE никак не хуже при прочих равных.


Это все пока все мягко говоря не встраиваемые системы для промышленных применений. Может кто-то путем конверсии дойдет, но это не сегодня. Пока кажется что скорей всего андроид.


И на CE тоже кроме малоактуального GTK.
Запустить то можно, а вот сделать добротный продукт за вменяемые усилия и деньги уже сложнее. Кто проходил знает. И вот тут на сейчас ИМХО WinCE хорошо подходит для нашей области. Что будет завтра посмотрим.

Не разобрался сходу, в Colibri SDK похоже хидер не доложили, поправил.
VS2005 генерирует другой код и использует wstrd, не разбирался в корректности.

ИМХО при оптимизации лучше помогать компилятору и писать так, чтоб он гадал поменьше. Например, будет ли использоваться дальше временная переменная и т.п.

Ага, у меня тоже, я из SDK к WINCE 6 взял.


Ну я вообще не понимаю, как так может быть. Пойду VS2005 искать. А ключи типа процессора у Вас какие? У меня ARM5T (/QRarch5t) и /Qxscale.

Код, кстати, тоже какой-то мутный, я не такой глубокий знаток ARM, сходу не понимаю, надо под отладчиком посмотреть. Но, во всяком случае, сохраняется 64 бита, это дает надежду. У меня, в Debug сборке, компилер MMX код не генерирует, эмулируя обычными операциями (возможно, это и правильно). Но что интересно, в таком режиме тоже в старших 32 битах возвращаемых Intrinsic функциями значений оказывается мусор, под отладчиком это прекрасно видно. То есть, такое поведение и задумывалось. Вообщем, не понимаю.

Пойду VS2005 искать, спасибо, что код проверили


Это я знаю, что помогать надо, но он же должен видеть, что до конца области видимости упоминаний этих переменных нет. Как ему еще указать? Я больше с IAR для AVR работаю, привык уже, что тот, если значение переменной не используется, все операции с ней выбрасывает. Если после этого другая переменная оказывается неиспользуемой, или функция - и их тоже, и т д. Бывает, чисто для отладки нужно переменную вставить, так только volatile static прокатывает. А MSVS, мерзавец, лепит в выходной код все, почем зря.

volatile хватает.


Может для АРМ и так, а для x86 вряд ли так.

Наверно все ж /QRxscale?
У меня по ошибке было /QRarch4t и /QRxscale, но и с /QRarch5t в этом месте тоже самое генерит.

Могу предположить, что в Debug эмулирует или потому, что в хидере есть условная компиляция, или в опциях для дебаг не разрешены intrisic /Oi. VS2005 и в сборке для дебаг делает тот же код.

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