[IgorKossak 0]

Может уже где то проскакивало, но поиском не нашёл.

Что касается:

/tmp/cc7ETq9C.s:508: Error: registers may not be the same -- `strexb r0,r0,[r1]'

/tmp/cc7ETq9C.s:533: Error: registers may not be the same -- `strexh r0,r0,[r1]'

на CodeSourcery рекомендуют сделать следующее:

Question

 

When compiling applications that contain or use the Cortex Microcontroller Software Interface Standard e.g. CMSIS (http://www.onarm.com/cmsis/) you may receive the following errors:

/tmp/ccaxp69S.s: Assembler messages:

/tmp/ccaxp69S.s:463: Error: registers may not be the same -- `strexb r0,r0,[r1]'

/tmp/ccaxp69S.s:488: Error: registers may not be the same -- `strexh r0,r0,[r1]'

 

How do I fix these "registers may not be the same" errors? Where do they come from?

 

Answer

 

Some versions of the CMSIS contain invalid inline assembly of the following form:

uint32_t __STREXB(uint8_t value, uint8_t *addr)

{

uint32_t result=0;

asm volatile ("strexb %0, %2, [%1]" : "=r" (result) : "r" (addr), "r" (value) );

return(result);

}

 

The first constraint =r on variable result is not correct, it should be =&r to indicate that the two registers used should not be the same e.g. early-clobber (this is required by the ARM Instruction Set Architecture).

 

To fix the error you must locate the invalid inline assembly and change the =r to =&r for the result register variable.

 

Often it is difficult to determine which source file was used to generate /tmp/ccaxp69S.s, to help with that problem add -save-temps to the compiler invocation to save the intermediate output to the current directory for your review.

 

This entry was last updated on 8 February 2012.

Т. е. сваливают всё не на компилятор, а на неграмотную строку в инлайн ассемблере. Может это и правильно?

Проверил их свежим тулчейном - работает.

PS Проверял только на старых проектах с CMSISv1.3

[ReAl 0]

В комплекте с тем, что раздаёт NXP для LPC

/**************************************************************************//**
* @file     core_cmInstr.h
* @brief    CMSIS Cortex-M Core Instruction Access Header File
* @version  V2.01
* @date     06. December 2010

Для IAR так вообще, выходит, сразу неправильно написано:

#elif (defined (__ICCARM__)) /*---------------- ICC Compiler ---------------------*/
/* IAR iccarm specific functions */
...
static uint32_t __STREXW(uint32_t value, volatile uint32_t *addr)
{
  __ASM("strex r0, r0, [r1]");
}

Для gcc надо править:

#elif (defined (__GNUC__)) /*------------------ GNU Compiler ---------------------*/
/* GNU gcc specific functions */
...
__attribute__( ( always_inline ) ) static __INLINE uint32_t __STREXB(uint8_t value, volatile uint8_t *addr)
{
   uint32_t result;

   __ASM volatile ("strexb %0, %2, [%1]" : "=r" (result) : "r" (addr), "r" (value) );
   return(result);
}

[klen 1]

Может уже где то проскакивало, но поиском не нашёл.

 

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

так что да, кто не хочет заморачиватся с тулсами - проще инлайн асм strbex и иже с ними порпавить в cmsis на использование трех операндов а не двух.

 

для конкретности отмечу - это косяг не gcc а binutils ( а именно ассемблера)

[Сергей Борщ 141]

а в доке на кортекс сказано что это в даном случае возможно. поэтому cmsis прав.

Где-то мне попадалось объяснение, со ссылками на доку от кортексов, что binutils таки прав, а неправ cmsis. Чуть ли не багтрекере binutils. Постараюсь найти позже.

 

[klen 1]

Где-то мне попадалось объяснение, со ссылками на доку от кортексов, что binutils таки прав, а неправ cmsis. Чуть ли не багтрекере binutils. Постараюсь найти позже.

давайте разбиратся с пристрастием. я помню - читал доку на http://infocenter.arm.com что можно таки strexb rX,rX, [rY].... а теперь еще раз освежаем в памяти и видим:

http://infocenter.arm.com/help/topic/com.a...a/BABFFBJB.html

вот цитата

Restrictions

In these instructions:

do not use PC

do not use SP for Rd and Rt

for STREX, Rd must be different from both Rt and Rn

the value of offset must be a multiple of four in the range 0-1020.

 

из чего я делаю вывод что : то что запершено для STREX не запрещено для STREXB !! ну явно то не написано что для STREXB нельзя...

в свежих CMSIS всетаки все версии иструкции закодены с разными регистрами.

вывод такой что CMSIS был с ошибками а binutils правильный НО для всех STREXB STREH пережимает ограничения на операнды также как и для STREX

 

может в описании ограничений на операнды имеется ввиду что STREX это = (STREX,STREXH,STREXB). тогда это явно надо писать а то я че угодно могу тогда домыслить.

 

и еще для раздумий... strexb r0, r0, [r1] у меня при тестах работало :) ревизия ядра с ошибками???? :laughing:

[Сергей Борщ 141]

давайте разбиратся с пристрастием.

Я так глубоко не копал. Наткнулся, записал на корочку, пошел дальше. Вот это сообщение (развязка в ответе на него): http://sources.redhat.com/ml/binutils/2011-09/msg00128.html

 

[AHTOXA 18]

может в описании ограничений на операнды имеется ввиду что STREX это = (STREX,STREXH,STREXB).

Я именно так и понял.

Кстати, сейчас попробовал kgp 20110328 + CMSIS от 19. July 2011, и получил:

strex    r2, r2, [ip]

Получается, у меня kgp как раз с исправлениями, а CMSIS - ещё нет?

 

 

Для gcc надо править:

   __ASM volatile ("strexb %0, %2, [%1]" : "=r" (result) : "r" (addr), "r" (value) );

Так не помогает, нужно: "=&r" (result).

[IgorKossak 0]

Отделил от темы про KGP.

[ReAl 0]

Так не помогает, нужно: "=&r" (result).

Ну так я и привёл две цитаты из файла, чтобы показать, что его нужно править :-)

 

[AHTOXA 18]

А, точно, я не так прочитал:)