Ошибка IAR или чтото еще? Опции

[Sergio66]

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

[Oldring]

Ответ прост. До тех пор, пока результат вычисления всего целочисленного выражения не отличается от стандартного способа вычисления с учетом того, что при переполнении промежуточных результатов возможно undefined поведение, компилятор может делать все, что угодно. Но только пока не отличается. Более того, важен даже не результат вычисления одного выражения, а последовательность записи значений в volatile переменные и вызовов системных функций. Все оптимизации программы, которые сохраняют запись в volatile переменные и ызовы системных функций - законные, все, которые приводят к изменению внешнего поведения программы - незаконны.

[Dog Pawlowa]

Ответ прост. До тех пор, пока результат вычисления всего целочисленного выражения не отличается от стандартного способа вычисления с учетом того, что при переполнении промежуточных результатов возможно undefined поведение, компилятор может делать все, что угодно. Но только пока не отличается. Более того, важен даже не результат вычисления одного выражения, а последовательность записи значений в volatile переменные и вызовов системных функций. Все оптимизации программы, которые сохраняют запись в volatile переменные и ызовы системных функций - законные, все, которые приводят к изменению внешнего поведения программы - незаконны.

Меня "правильность" компилятора мало интересует, я не д-р Туамосец.
Я рассматриваю правильность как максимально близкий результат к результату при перемножении в столбик
И получается такая незадача, что правильность зависит от значения переменных.
int a,b,c;
a*b/c при a=100, b=100, c=3 правильно будет (a*/c,
а при a=1000, b=1000, c=100 правильно будет a*(b/c).
Поэтому весь этот дискуссион не имеет смысла, тем более что автор не указал даже с какими числами он работал и предусмотрен ли запас по диапазону. Потому и залег на дно, видимо, предоставив нам возможность друг друга за чубы тягать

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

Хм... Например, оптимизатор IAR самостоятельно заменяет switch (a) {case ....} на vector[a] и создает массив функций при большом числе a.
Такое решение выглядит, как написали, или не выглядит?

[prottoss]

И получается такая незадача, что правильность зависит от значения переменных.
int a,b,c;
a*b/c при a=100, b=100, c=3 правильно будет (a* /c,
а при a=1000, b=1000, c=100 правильно будет a*(b/c).
Поэтому весь этот дискуссион не имеет смысла, тем более что автор не указал даже с какими числами он работал и предусмотрен ли запас по диапазону. Потому и залег на дно, видимо, предоставив нам возможность друг друга за чубы тягать

Вы специально со скобками дуру гоните, али как? Выражаясь Вашими формулами вопрос задаем так - ПОЧЕМУ:



Global_Value = a * b / c отличается от Local_Value = a * b / c;



Скобки и привидения к типам в обоих равенствах можете расставить по собственному усмотрению и вкусу, НО одинаково

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

Хм... Например, оптимизатор IAR самостоятельно заменяет switch (a) {case ....} на vector[a] и создает массив функций при большом числе a.
Такое решение выглядит, как написали, или не выглядит?

Как раз подходит под то, что говорит Oldring - снаружи функции и со switch (a) {case ....} и с vector[a] будет выглядеть одинаково, здесь же мы наблюдаем "не одинаково"

[Dog Pawlowa]

Вы специально со скобками дуру гоните, али как? Выражаясь Вашими формулами вопрос задаем так - ПОЧЕМУ:
Global_Value = a * b / c отличается от Local_Value = a * b / c;
Скобки и привидения к типам в обоих равенствах можете расставить по собственному усмотрению и вкусу, НО одинаково

Дуру? Отчасти
А на конкретный вопрос - конкретный ответ :

Да, сравнивать Global_Value = a * b / c и Local_Value = a * b / c при int a,b,c считаю некорректным.

Но можно сравнивать Global_Value = a * (b / c) и Local_Value = a *( b / c)
Или Global_Value = (long) a * (long) b / c и Local_Value = (long)a *(long) b / c, а еще лучше
Global_Value = ((long) a * (long) b ) / c и Local_Value = ((long)a *(long) b ) / c
И только после этого может появиться предположение об "ошибке".
У меня один и тот же проект постоянно портируется с MS VC на IAR AVR и обратно, да, было пару выбрыков у ИАРа, но в целом это вполне нормальный инструмент. За приемлемую цену

Все, пока автор не появится - ни строчки.

Сообщение отредактировал Dog Pawlowa - Dec 19 2006, 09:54

[Sergio66]

[/quote]
Дуру? Отчасти
А на конкретный вопрос - конкретный ответ :

Да, сравнивать Global_Value = a * b / c и Local_Value = a * b / c при int a,b,c считаю некорректным.

Но можно сравнивать Global_Value = a * (b / c) и Local_Value = a *( b / c)
Или Global_Value = (long) a * (long) b / c и Local_Value = (long)a *(long) b / c, а еще лучше
Global_Value = ((long) a * (long) b ) / c и Local_Value = ((long)a *(long) b ) / c
И только после этого может появиться предположение об "ошибке".
У меня один и тот же проект постоянно портируется с MS VC на IAR AVR и обратно, да, было пару выбрыков у ИАРа, но в целом это вполне нормальный инструмент. За приемлемую цену

Все, пока автор не появится - ни строчки.
[/quote]

Вот и автор.
Итак, что касается значения переменных. В приведенном случае:
data_temp_struct.temp = INJ_time * data_temp_struct.FREQ * PRODUCTIVITY / 20000;
long int INJ_time = от 74 000 до 75 000
unsigned int data_temp_struct.FREQ = 1000 (задается в процессе эксперимента)
PRODUCTIVITY = 5 (в данном случае)
long int Local_Value temp = INJ_time * data_temp_struct.FREQ * PRODUCTIVITY / 20000;
где long int Local_Value размещена в регистрах
в результате дает непонятное случайное число
заменив переменную temp на data_temp_struct.temp я добился того, что она теперь размещена в памяти. При этом все вычисления пошли верно.
Теперь о свертывании констант - как вы можете видеть, PRODUCTIVITY (=5)/ 20000 корректно никак свернуто быть не может (при данных значениях)

Был проделан сл эксперимент - формула была упрощена до вида:
long int Local_Value temp = INJ_time * PRODUCTIVITY;
И только...
Результат был неверным! Только размещение в памяти результирующей переменной дало эффект!!!
Т.о. у меня есть 2 подозрения -
1. глюк компиллятора
2. Коллизия с распределением памяти. Возможно стек возвратов, возможно стек данных.
Многие глюки у меня решались именно изменением этих параметров. Правда, в данном случае мне не удалось подобрать ничего правильного.
Дело в том, что проект очень большой порядка 10 000 строк. Большой расход памяти, задействованы почти все мыслимые и немыслимые аппаратные ресурсы и прерывания.
Возможно, компиллятор столкнулся с какими то внутренними проблемами при обработке такого сложного проекта.
Кстати, оптимизацию я полностью отключал. На это грешить не приходится.

Вот такие дела!

[Oldring]

Результат был неверным! Только размещение в памяти результирующей переменной дало эффект!!!

Так сразу после вычисленя выражения в регистрах результат правильный?

Ошибки компилятора, конечно, встречаются - но в 90% случаев подозрения на ошибки компилятора не оправдываются, оказываясь ошибками программиста. Поэтому утверждение про ошибку компилятора требуют более серьезных аргументов, чем "написал так - не работает, написал иначе - работает".

[Sergio66]

Результат был неверным! Только размещение в памяти результирующей переменной дало эффект!!!

Так сразу после вычисленя выражения в регистрах результат правильный?

Ошибки компилятора, конечно, встречаются - но в 90% случаев подозрения на ошибки компилятора не оправдываются, оказываясь ошибками программиста. Поэтому утверждение про ошибку компилятора требуют более серьезных аргументов, чем "написал так - не работает, написал иначе - работает".

Да нет же! Пока я не переразместил переменную, все считалось неверно. И в регистрах был неверный результат.

[Dog Pawlowa]

Да нет же! Пока я не переразместил переменную, все считалось неверно. И в регистрах был неверный результат.

Тот самый случай, когда лучше один раз увидеть, чем сто раз услышать.
А еще лучше совсем не видеть :-)
Я вот недавно буфер для sprintf малый сделал, и пол-дня искал причину затирания переменной, все ошибки в компиляторе искал и стек считал...
Нет?