[rezident 0]

Да и хрен на нее, хоть и static. На то и оптимизатор. Пользы от переменной никакой, накой ее держать?

Не его (компилятора) собачье дело! :) Пускай warning выдаст, а я уж сам решу нужна мне там переменная или не нужна. Насчет выбрасывания неиспользуемых функций - согласен, а вот насчет выбрасывания переменных типа static ...ммм... можно привести реальные примеры такого поведения с указанием конкретных компиляторов и параметров оптимизации?

 

[Petka 0]

Не его (компилятора) собачье дело! :) Пускай warning выдаст, а я уж сам решу нужна мне там переменная или не нужна. Насчет выбрасывания неиспользуемых функций - согласен, а вот насчет выбрасывания переменных типа static ...ммм... можно привести реальные примеры такого поведения с указанием конкретных компиляторов и параметров оптимизации?

 

static int foo;

int main (void){
  return 0;
}

 

На любом ненулевом уровне оптимизации gcc выкидывает foo

[Oldring 0]

Не его (компилятора) собачье дело! :)

 

По закону имеет право выкидывать... В смысле, по стандарту.

Какой компилятор реализует такую оптимизацию? Возможно, и никакой, так как это может требовать специальных усилий разработчиков компилятора без существенного выигрыша. Искать нужно среди компиляторов, занимающихся глобальной оптимизацией программы в целом. Они могут легко вычислить, что переменная не используется, и выкинуть её в ходе обычной оптимизации потоков данных. Поэтому крутые компиляторы для однокристаллок с их небольшими программами и широкими возможностями для глобальной оптимизации наиболее вероятные кандидаты. Вот только С с его адресной арифметикой существенно тормозит подобные оптимизации.

 

На любом ненулевом уровне оптимизации gcc выкидывает foo

 

Скорее всего выкидывает линкер, как объект, на который нет ни одной ссылки из программы.

[rezident 0]

На любом ненулевом уровне оптимизации gcc выкидывает foo

Хм. IAR тоже выбрасывает. :cranky:

А вот так уже нет. Но warning формирует в обоих случаях.

static int foo;

int main (void)
{ 
  foo = 1;
  return 0;
}

 

Скорее всего выкидывает линкер, как объект, на который нет ни одной ссылки из программы.

Нет, именно компилятор. Эта строка с объявлением переменной уже в asm-файле просто закоментарена компилятором.

 

[Гость MALLOY2]

Не зряж в IAR введен Extended keyword __root с помощю его никто никогда никого не выкинет.

[SapegoAL 0]

Понравилос :)

По таким постам легко отличать верующих от атеистов. Для верующих сила авторитета сильнее стандарта Си. :)

Вера здесь не при чём. Просто я, в отличее от Сергея, работаю только в компиляторе IAR. В связи с этим не берусь обобщать. Кроме того, Сергей не раз достаточно аргументировано отвечал приводя выдержки из стандарта.

 

Все остальные аргументы здесь уже привели. Они совпадают с моим подходом.

 

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

 

 

[aesok 0]

#include <avr/io.h>
#include <avr/interrupt.h>

extern void foo (void);
volatile int volatile * p_a;

int main()
{
  foo ();
  foo ();

  return 0;
}

void foo (void)
{
  static int a = 1;

  p_a = &a;

  a = 2;

  cli ();

  // предположим что в этот момент управление
  // передаеться обработчику прерывания и в нем
  // происходит чтение локальной переменной 'a'
  // через указарель 'p_a'.

  sei ();
  
  a = 3;
  return;
}

 

Вопрос: Какое значение получает обработчик прерывания через указарель 'p_a', если код скомпилирован с -Os? Кто считает что 2?

 

 

.global    foo
    .type    foo, @function
foo:
    ldi r24,lo8(a.1233)
    ldi r25,hi8(a.1233)
    sts p_a+1,r25
    sts p_a,r24
/* #APP */
;  23 "main.c" 1
    cli
;  0 "" 2
;  30 "main.c" 1
    sei
;  0 "" 2
/* #NOAPP */
    ldi r24,lo8(3)
    ldi r25,hi8(3)
    sts a.1233+1,r25
    sts a.1233,r24
    ret
    .size    foo, .-foo
.global    main
    .type    main, @function
main:
    rcall foo
    rcall foo
    ldi r24,lo8(0)
    ldi r25,hi8(0)
    ret
    .size    main, .-main
    .comm p_a,2,1
    .data
    .type    a.1233, @object
    .size    a.1233, 2
a.1233:
    .word    1

 

Правильный ответ: при первом вызове foo () 1, при последующих 3.

 

Анатолий.

Изменено 9 октября, 2010 пользователем aesok

[GetSmart 0]

Чтобы прерывания правильно обрабатывали глобальные переменные, меняющиеся вне прерывания, эти переменные должны быть волатильными. Есть такое правило.

Формально, p_a является волатильной и даже указывает (должна) на волатильную переменную, но в реале указывает на неволатильную. При присваивании p_a = &a должен был появиться варнинг. А в остальном, компилятор работая с "а" всё делает верно. Если бы между cli/sti был вызов функции, то перед вызовом в "а" была бы записана двойка.

[aesok 0]

Чтобы прерывания правильно обрабатывали глобальные переменные, меняющиеся вне прерывания, эти переменные должны быть волатильными. Есть такое правило.

Это я и пытаюсь показать на примере 777777

 

Формально, p_a является волатильной и даже указывает (должна) на волатильную переменную, но в реале указывает на неволатильную. При присваивании p_a = &a должен был появиться варнинг.

 

Никаких варингов нет.

 

А в остальном, компилятор работая с "а" всё делает верно. Если бы между cli/sti был вызов функции, то перед вызовом в "а" была бы записана двойка.

 

Да, с небольшим уточнением, если эта дополнительная функция проинлайнилась в foo () и указатель p_a в ней не используеться, то записи двойки в 'a' не будет.

 

Анатолий.

[777777 0]

Правильный ответ: при первом вызове foo () 1, при последующих 3.

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

a = 2;

a = 3;

Результат выполнения этой программы - занесения 3 в переменную a. Но это последнее присваивание компилятор не имеет права выбрасывать потому что a - static! И этот результат может понадобиться при последующих вызовах этой функции.

 

В моем случае последовательность была такая:

    uint8_t cmd[3] = { 8, mn, 0 };

    pTWI = cmd;
    SendSLA();

Здесь компилятор не имеет права выбрасывать ничего, даже если бы pTWI было не volatile потому что:

а) адрес cmd присваивается глобальной переменной, сделовательно cmd используется и он должен быть инициализирован;

б) pTWI - глобальная переменная, следовательно она может использоваться в других функциях, а значит по выходу из функции в ней должен быть адрес cmd;

в) более того, следом вызывается некая глобальная функция, поэтому компилятор обязан предположить, что pTWI может использоваться в этой функции, следовательно адрес cmd должен быть присвое ей до вызова SendSLA

После того как я сделал массив static ограничений стало еще больше.

[777777 0]

Чтобы прерывания правильно обрабатывали глобальные переменные, меняющиеся вне прерывания, эти переменные должны быть волатильными. Есть такое правило.

Обалденное определение, мне нравится. А что значит "правильно обрабатывали"? А как можно обрабатывать неправильно?

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

An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3. Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously. What constitutes an access to an object that has volatile-qualified type is implementation-defined.

Таким образом, volatile должны быть объявлены только те переменные, которые с точки зрения компилятора не меняются исходя из транслироемого кода.

 

 

Если бы между cli/sti был вызов функции, то перед вызовом в "а" была бы записана двойка.

Вообще говоря да, компилятор обязан предположить, что 'a' может потребоваться в той функции, но в данном случае она static и поэтому из той функции недоступна.

[_Pasha 0]

компилятор обязан предположить

Вот мы все на языке лирики, а меж тем - чистая теория графов :) удалил вершину - и нет проблемы переменной

[demiurg_spb 0]

Разумеется...

...последнее присваивание компилятор не имеет права выбрасывать потому что a - static!

Вы не правы. Привязались к статику уак банный лист:-)

Он не для этого задуман. И все ваши домыслы можно поставить с ног на голову путём изменения опций компилятора и линкера.

Остыньте и сделайте два-три глубоких вдоха. В этом споре вы уже проиграли. Сэ ля ви:(

 

PS

aesok, с возвращением!

[777777 0]

Вы не правы. Привязались к статику уак банный лист:-)

Он не для этого задуман. И все ваши домыслы можно поставить с ног на голову путём изменения опций компилятора и линкера.

Остыньте и сделайте два-три глубоких вдоха. В этом споре вы уже проиграли.

А для чего же он создан? Приведите раздел стандарта который это объясняет. В крайнем случае, приведите пример программы с набором опций компилятора и линкера. Вы ничего этого не сделали, но почему-то объявляете, что я проиграл.

 

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

 

[GetSmart 0]

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

Это такая же голимая интерпретация как и я писал об volatille :)

Я хотя бы для себя ввёл то правило, являющееся следствием оптимизации компиляторов. То есть "моё" правило, напрямую не касалось определения volatille, а просто юзало его.

 

Статик просто размещает переменную в каком-то там сегменте (bss или др.). И всё. Остальное на совести компилятора.