Доброго времени!
Подскажите, как заставить компилятор в Winavr генерить правильный код.
Нужно


Приведение к 32-битам - это безумное количество кода.
Надо, чтоб генерился код примерно такой (имена регистров не важны):


Бился головой о стену - ниасилил компилер такой красоты. А очень надо. Если кто уже получал такое чистым Си, поделитесь, пожалуйста, опытом.

Прочтите внимательно предыдущий пост.
Я показал, что при b=1 можно применять. Но результат несколько неожиданный.

При a=-32768 нельзя.
P.S. Если выдает ошибку при b=1, то это бага компилятора, которая заключается в безусловной подмене операции /256 операцией взятия старшего байта с последующим знаковым расширением. Согласитесь, что операции сразу в дополнительном коде и беззнаковые с последующим получением отрицательного числа должны давать одинаковый результат на множестве [-32767..+32767]

Вот неожиданность меня и сбила с толку. Перечитал, понял



А это я вечерком проверю.

Можно вопрос немного в сторону? Для чего применяется подобное масштабирование? Ну, пару примеров? А то вижу что штука хорошая, а куда применить - не могу придумать

Например, выдаем биполярный сигнал через 10-бит PWM. Базовая линия сигнала (наш ноль) будет на отметке PWM_OFFSET=512. А на АЦП висит резистор громкости, 8-бит достаточно.


Проверил на своем gcc4.2.2 выражение
c=(int32_t) a*b/256; компилится правильно при b=1, a=-32767, т.е. и в виде константного выражения и в виде реальных вычислений результат = 0xFFFFFF81

Я добрался до АВРки, продолжаю

Урезал осетра, запустил цикл с -32767...
Упс, при a = -32766 и b = 128 пишет:
ошибка, i1 = -16382, i2 = 49153.
Я в шоке Проверяю на куркуляторе - должно получиться -16383. Окей, ещё одна дырочка в области применения. Но это ерунда
Интереснее другое: как выражение при i = -32766 и b = 128 дало 49153?!

проверял с
avr-gcc.exe (GCC) 4.3.0 20080111 (experimental)
avr-gcc.exe (GCC) 4.4.0 20080530 (experimental) от klen-a
и
avr-gcc.exe (GCC) 4.1.2 (WinAVR 20070525)

Это опять я глючу, или таки бага компилятора?

Это глюки не компилера, а отладчика, в котором Вы все это смотрели.
Судите сами: 49153 = C001, опять же, в дополн коде получим 3FFF, т.е 16383

Спасибо, что не успокоились, а то я так и прошляпил бы эти грабли (что врет на единицу).
В принципе, пофиксил. Надо порядок умножений попробовать поменять. Бит SREG.C выскакивает в mulsu когда signed <0. Сейчас тоже позанимаюсь.

Ничего интересного: 49153 это 0xC001 или -16383.

Убери unsigned из объявления переменой i2.

Анатолий.

PS: В следующий раз посылайте тестовые примеры полностью, с объявлениями перемеренных.



Это глюки не отладчика а програмера. Надо правильно выбирать типы переменных.

Сообщение отредактировал aesok - Jun 3 2008, 18:58

Я на железке смотрю, так сказать, живьём.



Не могу. Его там нет Мне что, тестовый пример пихать в каждое своё сообщение? Я его уже два раза приводил.

PS. Я почти на 100% уверен, что глюк мой, а не компилятора. Только не могу понять где...

Короче, не выходит каменный цветок.
Куча исключений.
1. При b=0x80 врет на 1
2. Надо повнимательней к переполнениям, т.к. например -1 * 0xff /0x100 даже на "куркуляторе" дает чушь, напоминающую о необходимости обрабатывать исключения.




Наверное, куда-то девается (игнорируется) знаковое расширение в старших байтах.
GCC4.2.2 на аврстудии показывает все правильно.

Ну ничего, всё равно пригодится. Для некритичных к точности но критичных ко времени вычислений (как в примере с ШИМом)




Я уже всю голову сломал. Есть ф-я вывода int на дисплей:
nokia_put_int(int i);

есть два инта:
Первый int (i1, -16382 или C002) отображается нормально, в виде отрицательного значения. А вот i2 (-16383 или C001) - почему-то трактуется как unsigned... Вот и пойми тут, в чём разница...

Ладно, вечерком ещё поковыряю...

Я лопух:-)



последняя строчка была: nokia_put_uint(i2);
Буковку проглядел