[sz36 0]

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

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

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

 

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

   int Temp[64];
   __m64 X;
   X.m64_i64=0x1122334455667788;
   __m64 Y;
   Y.m64_i64=0x8877665544332211;   
   __m64 A=_mm_macz_pi16(X, Y);     (!)
   Temp[0] = A.m64_u32[0];
   Temp[1] = A.m64_u32[1];

 

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

 

  00040 ed9d1144         wldrw       wr1, [sp, #0x110]
  00044 ed9d0146         wldrw       wr0, [sp, #0x118]
  00048 e3a03040         mov         r3, #0x40
  0004c ee710100         wmacsz    wr0, wr1, wr0
  00050 ed8d0144         wstrw       wr0, [sp, #0x110]  ---[b]баг компилятора?[/b]
  00054 e59d2114         ldr           r2, [sp, #0x114]
  00058 e59d0110         ldr           r0, [sp, #0x110]
  0005c e58d0010         str           r0, [sp, #0x10]
  00060 e58d2014         str           r2, [sp, #0x14]

 

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

 

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

 

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

 

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

 

 

 

[SBE 1]

Все процессоры с ядрами PowerPC, SPARC, MicroBlaze, Motorola 68000, M32R (Renesas), TMS320C6x.

Это я ещё всякую экзотику не брал типа вымерших AVR32.

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

 

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

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

 

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

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

 

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

И на CE тоже кроме малоактуального GTK.

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

 

[SBE 1]

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

Не разобрался сходу, в Colibri SDK похоже хидер не доложили, поправил.

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

; 74   :     int Temp[64];
; 75   : 
; 76   :     __m64 X;
; 77   :     X.m64_i64=0x1122334455667788;
; 78   :     __m64 Y;
; 79   :     Y.m64_i64=0x8877665544332211;   

  00044    e59f10a0     ldr         r1, [pc, #0xA0]
  00048    e59f0098     ldr         r0, [pc, #0x98]
  0004c    ee203012     tmia        wr0, r2, r3
  00050    e59f308c     ldr         r3, [pc, #0x8C]
  00054    e59f2084     ldr         r2, [pc, #0x84]
  00058    e3a04001     mov         r4, #1
  0005c    e58d3000     str         r3, [sp]
  00060    e58d2004     str         r2, [sp, #4]

; 80   :     __m64 A=_mm_macz_pi16(X, Y);    // (!)

  00064    eddd1100     wldrd       wr1, [sp]
  00068    e3a0e005     mov         lr, #5
  0006c    e58d1008     str         r1, [sp, #8]
  00070    e58d000c     str         r0, [sp, #0xC]
  00074    eddd0102     wldrd       wr0, [sp, #8]
  00078    ee28e014     tmiaph      wr0, r4, lr
  0007c    e3a04002     mov         r4, #2
  00080    e3a0e008     mov         lr, #8
  00084    ee710100     wmacsz      wr0, wr1, wr0
  00088    ee2fe014     tmiatt      wr0, r4, lr
  0008c    edcd0102     wstrd       wr0, [sp, #8]
  00090    ec523000     tmrrc       r3, r2, wr0

; 81   :         Temp[0] = A.m64_u32[0];
; 82   :     Temp[1] = A.m64_u32[1];

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

 

[sz36 0]

Не разобрался сходу, в Colibri SDK похоже хидер не доложили, поправил.

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

 

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

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

 

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

 

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

 

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

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

 

 

 

[Артём__ 0]

Бывает, чисто для отладки нужно переменную вставить, так только volatile static прокатывает.

volatile хватает.

 

А MSVS, мерзавец, лепит в выходной код все, почем зря.

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

[SBE 1]

А ключи типа процессора у Вас какие? У меня ARM5T (/QRarch5t) и /Qxscale.

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

Наверно все ж /QRxscale?

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

 

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

 

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