LINUX.ORG.RU

thumb -> arm вызов

 , ,


0

2

В библиотеке libmad есть единственная функция, написанная на ассемблере, для режима arm. gcc по умолчанию генерирует thumb код, и режим при вызове этой функции не переключает. Есть ли какие-нибудь способы сказать gcc, что нужно переключить режим при вызове этой функции, или может быть, макросы чтобы узнать для какого режима сгенерирует код gcc и переключить режим вручную?

-mthumb-interwork проблему не решает.

$ gcc -v
Используются внутренние спецификации.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
Целевая архитектура: arm-linux-gnueabihf
Параметры конфигурации: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Модель многопоточности: posix
gcc версия 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 
★★★

Режимы ARM/Thumb переключаются автоматически (по выравниванию PC).

Никаких специальных усилий для этого GCC делать не должен.

Есть возможность посмотреть (скажем, GDB), что именно не так?

anonymous ()
Ответ на: комментарий от anonymous
   0xb6ae4c6a <III_decode+2842>:	mov	r1, r10
   0xb6ae4c6c <III_decode+2844>:	mov	r2, r4
   0xb6ae4c6e <III_decode+2846>:	bl	0xb6ae5c48 <_III_imdct_l>
   0xb6ae4c72 <III_decode+2850>:	ldr.w	r12, [sp, #28]
   0xb6ae4c76 <III_decode+2854>:	ldr	r1, [r6, #0]
   0xb6ae4c78 <III_decode+2856>:	movs	r3, #0

_III_imdct_l - та самая функция, и если бы там было «blx _III_imdct_l», то режим бы переключился

AptGet ★★★ ()
Ответ на: комментарий от bakugan

Да, это работает, но это немного грубо. К тому же, можно пометить функцию .thumb_func:

    .text
    .align 2
    .thumb_func
    .global III_imdct_l
    .global _III_imdct_l
III_imdct_l:
_III_imdct_l:
    bx      pc

    .arm
    .align

    stmdb   sp!, { r2, r4 - r11, lr }   @ all callee saved regs, plus arg3
...

и тогда gcc -marm генерирует для вызова такие обертки:

00009dc8 <__III_imdct_l_veneer>:
    9dc8:   e59fc004    ldr ip, [pc, #4]    ; 9dd4 <__III_imdct_l_veneer+0xc>
    9dcc:   e08fc00c    add ip, pc, ip
    9dd0:   e12fff1c    bx  ip
    9dd4:   fffff115    .word   0xfffff115

а вот для thumb->arm никаких оберток нет.

AptGet ★★★ ()
Ответ на: комментарий от AptGet

не, мой gas не понимает -implicit-it=

ну как это не понимает

Параметры конфигурации: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5'

https://wiki.ubuntu.com/Mobile/ARMv7AndThumb#Slide_4

вообще непонятна тяга к libmad - она полезна когда у процессора нет FPU чтобы все вычисления с целыми числами делать - не припомню ниодного armv7-a без VFP, без NEON-а есть. mp3 изначально алгоритм с потерей информации - фиксированная точка тут ничего уже не исправит.

bakugan ()
Ответ на: комментарий от bakugan
 gcc -DHAVE_CONFIG_H -I. -DFPM_ARM -DASO_INTERLEAVE1 -DASO_IMDCT -D_FORTIFY_SOURCE=2 -Wall --param=ssp-buffer-size=4 -Wformat -Wformat-security --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -O2 -fomit-frame-pointer -mthumb -Wa,-implicit-it=thumb -c version.c  -fPIC -DPIC -o .libs/version.o
as: unrecognized option '-implicit-it=thumb'

ac-100, tegra 2.

вообще непонятна тяга к libmad - она полезна когда у процессора нет FPU чтобы все вычисления с целыми числами делать - не припомню ниодного armv7-a без VFP, без NEON-а есть. mp3 изначально алгоритм с потерей информации - фиксированная точка тут ничего уже не исправит.

просто она сломана в релизе убунты, и куча плееров не работает

AptGet ★★★ ()
Ответ на: комментарий от bakugan

А где-нибудь вообще описано по-человечески (то есть не в исходниках), как gcc решает вопросы про arm<->thumb?

anonymous ()
Ответ на: комментарий от AptGet

ac-100, tegra 2

вот почему единственный доступный arm-ноутбук сделали на самой ужасной с точки зрения разработчика SoC?

1. проприетарный gpu вместо neon — очень удобно, спасибо. 2. никакой документации, разумеется, нет 3. про то, через какое место там подключается периферия, лучше вообще не говорить

anonymous ()
Ответ на: комментарий от anonymous

вот почему единственный доступный arm-ноутбук сделали на самой ужасной с точки зрения разработчика SoC?

Да, это фейл. Я бы предпочел чип от freescale, правда не знаю что там с видео. Но думаю не хуже чем fbdev сейчас на тегре.

AptGet ★★★ ()
Ответ на: комментарий от AptGet

Я бы предпочел чип от freescale

ну есть efika mx smartbook http://www.genesi-usa.com/products/smartbook

только оно ощутимо медленнее tegra 2, и в ларьках не продается.

по идее у фрискале с видео получше, во всяком случае, на i.mx53 убут умеет рисовать, видел лично.

anonymous ()
Ответ на: комментарий от anonymous

ну и даташиты, конечно, у фрискале есть на их кристаллы.

anonymous ()
Ответ на: комментарий от anonymous

вот почему единственный доступный arm-ноутбук сделали на самой ужасной с точки зрения разработчика SoC?

Они все одинаково огорожены, по крайней мере там где касается аудио/видео/графики.

1. проприетарный gpu вместо neon — очень удобно, спасибо.

Если кратко - на данный момент gcc неспособен делать оптимизации под NEON, тесты показали что armhf без него работает быстрей чем при использовании NEON. Debian, Ubuntu и прочие счас массово переходят на armhf.

bakugan ()
Ответ на: комментарий от bakugan

Это я ошибся из-за убунтовской вики :) -mimplicit-it=thumb

Хм, я искал в man as по *impl*, но ничего не нашел :) В любом случае, собралось, но не работает. Также, оберток в коде опять нет:

   0xb6ae4c68 <III_decode+2840>:	ldr	r0, [sp, #24]
   0xb6ae4c6a <III_decode+2842>:	mov	r1, r10
   0xb6ae4c6c <III_decode+2844>:	mov	r2, r4
   0xb6ae4c6e <III_decode+2846>:	bl	0xb6ae5c48 <_III_imdct_l>
   0xb6ae4c72 <III_decode+2850>:	ldr.w	r12, [sp, #28]
   0xb6ae4c76 <III_decode+2854>:	ldr	r1, [r6, #0]
AptGet ★★★ ()
Ответ на: комментарий от bakugan

Они все одинаково огорожены, по крайней мере там где касается аудио/видео/графики

неверно.

у многих (например, marvell) аудио — обычный ac97. что там огорожено? вот передо мной лежит даташит, в котором подробно описана реализация кодека на их кристалле.

что касается видео/графики — gpu все проприетарные, да. а вот фреймбуфер может быть человеческим и человечески описанным, а может не быть. обычно, перед тем, как захочется 3d, появляется желание хоть что-то увидеть, а на той же тегре это весьма непросто.

gcc неспособен делать оптимизации под NEON, тесты показали что armhf без него работает быстрей

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

простой пример удобства neon — memcpy. написанное на neon практически точно в два раза быстрее (что и не удивительно), и armhf тут ни при чем.

anonymous ()
Ответ на: комментарий от AptGet

В любом случае, собралось, но не работает.

ой, ну сколько можно страдать. напиши ты уже этот blx руками

void dothumb(){asm volatile("blx %0":"r"(_III_imdct_l));}
anonymous ()
Ответ на: комментарий от anonymous

ой, ну сколько можно страдать. напиши ты уже этот blx руками

Я написал как бы уже :) проблема в том, что так не взлетит, если собирать с -marm.

AptGet ★★★ ()
Ответ на: комментарий от anonymous

обычный ac97. что там огорожено? вот передо мной лежит даташит, в котором подробно описана реализация кодека на их кристалле.

Я не про это, ac97 это интеловский стандарт описывающий интерфейс, протокол и даже распиновку и размеры для аудио цап-ацп, а про аппаратные аудио/видео кодеры-декодеры.

векторный код как правило легче писать руками, только при отсутствии neon это как-то не получается.

Ну и много ты этого кода руками напишешь ? По иронии судьбы как раз инженер genesi (efika mx которую ты расхваливаешь) особо рьяно тестирует и нахваливает armhf :)

http://www.youtube.com/watch?v=qWUd4TAEqTM

bakugan ()
Ответ на: комментарий от AptGet

проблема в том, что так не взлетит, если собирать с -marm

что-то я уже запутался.

проблема была в том, что ассемблерный кусок на arm, а все остальное собирается в thumb.

теперь мы пришли к проблеме вызова кода arm из arm. как так получилось и что там не работает?

anonymous ()
Ответ на: комментарий от anonymous

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

AptGet ★★★ ()
Ответ на: комментарий от bakugan

аппаратные аудио/видео кодеры-декодеры

это наверное. особо не трогал.

Ну и много ты этого кода руками напишешь ?

я, в общем, не мультимедией занимаюсь, так что как раз хватает. я совершенно не спорю, что кому-то удобнее использовать vfp.

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

Ну и много ты этого кода руками напишешь ? По иронии судьбы как раз инженер genesi (efika mx которую ты расхваливаешь) особо рьяно тестирует и нахваливает armhf :)

ну, ее я не хвалю, т.к. в руках держал примерно с неделю. человек попросил ноутбук на freescale — я показал.

к сожалению, у меня сейчас нет звука, так что выяснить, о чем там в видео речь, не могу. судя по аннотации, в которой ничего про neon нет, могу сказать, что конечно hard float круче soft float, ага. а реальная машина быстрее эмулятора, да. не могу не согласиться.

я вообще поражаюсь, как люди столько времени, имея vfp почти везде, жили с эмуляцией fma. то есть призывы к hf мне напоминают уверения в пользе дыхания. :-)

anonymous ()
Ответ на: комментарий от AptGet

Я вставлял blx _label_

значит, не зря я таки аж целую строчку правильного кода привел.

так работает оно наконец?

anonymous ()
Ответ на: комментарий от anonymous

судя по аннотации, в которой ничего про neon нет, могу сказать, что конечно hard float круче soft float, ага. а реальная машина быстрее эмулятора, да. не могу не согласиться.

Если погуглишь - без аннотации поймешь что речь идет о замене -mfloat-abi=softfp (передача параметров через регистры общего назначения) на hard - принудительно использует FPU, в принципе в качестве FPU можно указать и neon, но он не на всех процессорах есть к тому же не полностью совместим со стандартом IEEE и как показывают тесты в gcc с векторизацией все плохо, так что никому этот neon не впился. Почему именно сейчас началось - нормальная подержка сравнительно недавно появилась

The combination of -mfpu=vfp and -mfloat-abi=hard is not available in FSF GCC 4.4

bakugan ()
Ответ на: комментарий от anonymous

так работает оно наконец?

Да, работает. Спасибо.

AptGet ★★★ ()
Ответ на: комментарий от bakugan

в принципе в качестве FPU можно указать и neon, но он не на всех процессорах есть к тому же не полностью совместим со стандартом IEEE и как показывают тесты в gcc с векторизацией все плохо, так что никому этот neon не впился.

еще раз:

1. я не призываю считать плавающую точку в neon. считайте где хотите.

2. hardfp однозначно круче softfp. тут двух разных мнений быть не может. то, что gcc/linux/whatever не умело его раньше — это стыд и позор, а то, что сейчас умеет — это вовсе не передовое достижение с фанфарами, а повод для вопроса «а раньше-то куда смотрели?»

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

Почему именно сейчас началось - нормальная подержка сравнительно недавно появилась

> The combination of -mfpu=vfp and -mfloat-abi=hard is not available in FSF GCC 4.4

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

anonymous ()
Ответ на: комментарий от anonymous

2. hardfp однозначно круче softfp.

Однозначно ? Наверно ты путаешь softfp (параметры передаются в РОН а использовать fpu или софтовую реализацию плавучки определяется в рантайме на целевой системе) и soft - используется програмная реализация вычислений с плавающей точкой (противоположность hard)

3. neon весьма полезен для *специфических* задач оптимизации

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

ARMv8 improves this support dramatically. The floating-point register set is now 32 registers, each of which is 128 bits wide, allowing it to store four single-precision or two double-precision values. The architecture now fully supports the IEEE 754 standard for floating point, including all of the strange rounding modes and not-a-number values (for example, the result of division by zero) that the specification requires.

bakugan ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.