Столкнулся со следующей проблемой:
Использую IAR 4.20А
В программе (в функции) перемножаю два числа типа long int. Одно из них - локальная временная переменная (для упрощения расчетов). Результат умножения получается неверным (просто бред!). АВР СТУДИО показывает, что компиллятор размещает временную переменную в регистрах.
Вылечил данную проблему тем, что правдами - неправдами добился того, чтобы компиллятор разместил данную переменную в памяти. Вот только тогда все и заработало.
Кто нибудь может прокомментировать этот случай?

Показывайте код.

Вот такой код:
unsigned long int temp = INJ_time * data_temp_struct.FREQ * PRODUCTIVITY / 20000;
тип INJ_time - unsigned long int. Эта переменная локальная.
PRODUCTIVITY - константа
Так вот, переменная temp размещалась компилятором в регистрах и все было плохо

Теперь я переменную temp сделал членом локальной структуры data_temp_struct
Т.о. она стала размещаться в памяти а не в регистрах. Вот с этого все и заработало.
data_temp_struct.temp = INJ_time * data_temp_struct.FREQ * PRODUCTIVITY / 20000;

Ну, так все правильно. Компилятор перед генерацией производит свертку констант, т.е. вычисляет значение PRODUCTIVITY / 20000. Естественно, оно будет вычисленно неточно. Поставьте в выражении скобки в нужных местах. Еще советую объявить константы как long, тогда погрешность в вычислении уменьшится.

А что, если переменная размещена не в регистрах, а в памяти, свертка констант не производится? Или это происходит как то иначе?
Я ведт ничего не поменял, просто добился иного размещения в памяти переменной!!! И никаких скобок.И без них все заработало. Нет! Дело не в этом!!!

Опишите проблемму полностью:

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


Анатлий.

Сообщение отредактировал aesok - Dec 18 2006, 15:23

Послушайте! :-)
Вам предлагают дело - записать формулу ПРАВИЛЬНО.
Разбираться в особенностях компилятора в случае неправильной записи - очень неблагодарное дело.
А еще можно начать разбираться в особенностях различных компиляторов. Путь в никуда.
Меня такие вещи давно не беспокоят - побольше скобок и преобразования типов.
И ффсе!

Скобки расставлял. Это ни к чему не привело. Проблема исчезла повторяю только после того, как переменная была размещена в памяти а не в регистрах!!!

Сказанно, если размещать переменную локально, не вычисляется, если глобально - вычислятся - при чем тут скобки???

Если Вы смотрите на получаемое значение в окошке Watch AVR Studio, то тогда у Вас
все в порядке. Смотрите на результат в регистрах он там правильный.

AVR Studio НЕ гарантирует что локальные переменные соптимизированные компилятором
(хранящиеся в регистрах) будут правильно показываться в Watch.

А скобочки все-таки поставьте
конечно если у Вас PRODUCTIVITY / 20000 - целое, тады не надо

1. Было сказано так "побольше скобок И ПРЕОБРАЗОВАНИЯ ТИПОВ".
2. Ообще-тоавтор он мог бы разместить здесь ассемблерный текст и гадание на гуще не состоялось бы.
2. Видел подобный случай - я работал под IAR, клиент стал компилировать под ICC. Результат усреднения значений АЦП считался по разному. Именно из-за особенностей работы компилятора в случае некорректного написания программы. И что? И ничего.

Это было сказанно, вернее посоветованна, Вами, и товарищем aesok. Смысл же вопроса автора топика был именно в том, что сказал я - если размещать переменную локально, не вычисляется, если глобально - вычислятся , при чем здесь cкобки, позвольте? У меня, в данный момент, есть тоже подобный фокус в программе, которой сейчас занимаюсь. Если обсуждаемая сдесь проблема не решится, поделюсь своей...

Не имеет права. Ассоциативность этих операций фиксирована - слева направа.

Нужно сравнивать листинг того, как получается неправильно, и того, как получается правильно. Иначе можно много фантазировать.



Все записано правильно.

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

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

Тогда мы по разному понимает слово "правильно". Я включал в это понятие учет возможности переполнения и максимальной независимости от констант. А Вы - нет?

Дело в том, что Билл написал просто чепуху про "естественную" свертку целочисленных констант перед вычислением выражения, а Вашего предложения я вообще почему-то не вижу в истории переписки. Так как так и не была озвучена информация про диапазоны операндов, хотелось бы все-таки увидеть, что именно Вы считаете "правильной" записью данного выражения, если это понятие "правильности" отличется от формальной правильности. Хотелось бы также узнать Ваше мнение по следующему вопросу: существует ли с точки зрения стандарта языка программирования С какая-либо разница между выражениями



и



?

И, кстати, считаете ли Вы что компилятор имеет право выражение



заменить на



?