Ктонибудь когда нибудь организовывал на С на AVR асемблерную операцию сдвига в бит C (Cerry) и возможно ли это вообще на С ???

Собственно любой сдвиг выталкивает крайний бит в с.

a>>=1 - младший бит попадает в С

А какой в этом тайный смысл, если не секрет. Просто пиши на С, а с регистрами, битами, стеками это уже дело компилятора возиться. Сколько пишу для AVR и ARM на С/С++ ни разу не было желания в Cerry что-то задвигать.

я бы такого не утверждал, это не предусмотренно Сишными стандартами, поэтому лучше на это не расчитывать

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

Логический сдвиг гарантируется только для целых чисел без знака.
А для других типов данных зависит от конкретной реализации компилятора.

Теоретически можно сделать это ручками. Практически это не имеет никакого смысла, поскольку воспользоваться флагами реально только из ассемблера. А если ассемблер, то зачем сдвиг в Си делать?

А какой в этом тайный смысл, если не секрет. Просто пиши на С, а с регистрами, битами, стеками это уже дело компилятора возиться. Сколько пишу для AVR и ARM на С/С++ ни разу не было желания в Cerry что-то задвигать.

[/quote]

Тайный смыс вот какой - в своей проге я создаю регистр флагов (обычно R15) сканировать его можна 2-мя способами:
1)
for(;;)
{
unsigned char buff=reg_flag;
if ((buff & 0x01) == 0x01){time();}
if ((buff & 0x02) == 0x02){indi ();}
if ((buff & 0x04) == 0x04){klava ();}
if ((buff & 0x08) == 0x08){break ;}
}

2)
for(;;)
{void (* Pfunk[3])()={minute,save,analiz_ADC};
unsigned char buff=reg_flag;
unsigned char count=2;
for(;;)
{
if ((buff&0x01)==0x01) {(* Pfunk[count])();}
buff>>=1;
count--;
if ((SREG&0x04)==0x04){break;}//if negative flag=1
}
}
прои большом количестве функций, которые необходимо адресовать при помощи регистра флагов способ 2 даёт меньший обьём кода в асме, просто хочу его не многа изменить.

Если ваш компилятор допускает ассемблерные вставки, может, стоит вставить этот кусок на асме? При таком ходе бит 100% попадет в Сarry и при переходе на другой компилятор не будет сюрпризов

Компилятор IAR под AVR версии 4.10, асемблерные вставки делать под него, скажу прямо - полный отстой. Как я видел перед асмовской вставкой он сначала сохканяет на стеке регистры начиная с R16 а потом достаёт их назад, что раздувает код.

Я не сильно большой знаток С, но не проще ли было записать так:

, только объявить counter как signed...

Да, кстати, я не поленился и написал что-то типа первого варианта,
скомпилировал и получил примерно такой код:

Ну и куда уже короче-то? Нет, ну конечно мог бы компилер в R16 и не пересылать, но по моему и так неплохо. Не говоря уже о том, что первый вариант на порядок читабельнее.

А во втором - может, общий код будет и покороче. Но. Учтите что раздуется код инициализации (константы-указатели), и работать цикл будет прилично медленнее.

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

А кто мешает использовать переменную с полями битов:
void fun1(void)
{
}
void fun2(void)
{
}
void fun3(void)
{
}

void main(void)
{
struct myflags{
char flag1 :1;
char flag2 :1;
char flag3 :1;
}m;
m.flag1=1;
m.flag2=m.flag3=0;
if(m.flag1!=0)fun1();
if(m.flag2!=0)fun2();
if(m.flag3!=0)fun3();
}
Разворачивается буквальнов в три команды и никаких сдвигов:
\ 00000008 FB80 BST R24, 0
\ 0000000A F40E BRTC ??main_0
\ 0000000C .... RCALL fun1
21 if(m.flag2!=0)fun2();
\ ??main_0:
\ 0000000E FB81 BST R24, 1
\ 00000010 F40E BRTC ??main_1
\ 00000012 .... RCALL fun2
22 if(m.flag3!=0)fun3();
\ ??main_1:
\ 00000014 FB82 BST R24, 2
\ 00000016 F40E BRTC ??main_2
\ 00000018 .... RCALL fun3