Глюки IAR C for AVR 3.10C

Привет All!

IAR C/EC++ Compiler for AVR

3.10C/W32 [Evaluation] (3.10.3.3) - кряканый

кристал Mega16

При достижении проектом некоторого размера (исходников ~130КБ) начались очень странные глюки при использовании в оптимизации "кластеризация переменных". Это у всех так, или у меня всетаки с проектом чево-то нето???

Пробовал тот-же проект компилить IAR C/EC++ Compiler for Atmel AVR 2.26.3.0 - но не поубирал #pragma inline=forced (на которые он ворнинги повыдавал) - после прошивки контроллер вообще не стартовал??

Aleksandr

... Чем меньше женщину мы любим..., тем больше песен у Тату.

Reply to
Aleksandr Popruga
Loading thread data ...

Всем привет!

Aleksandr Popruga писал к All 07.12.2004:

AP> IAR C/EC++ Compiler for AVR AP> 3.10C/W32 [Evaluation] (3.10.3.3) - кряканый

AP> При достижении проектом некоторого размера (исходников ~130КБ) начались AP> очень странные глюки при использовании в оптимизации "кластеризация AP> переменных". Это у всех так, или у меня всетаки с проектом чево-то AP> нето???

Вряд ли много кто пользуется этой версией, так что достоверно ответить затруднительно. Но раз текущая версия уже 3.20D, то очевидно, что ошибки в предыдущих версиях были. У меня объем исходников 600кб и на v3.20C при максимальной оптимизации глюков пока не замечено.

AP> Пробовал тот-же проект компилить IAR C/EC++ Compiler for Atmel AVR AP> 2.26.3.0 - но не поубирал #pragma inline=forced (на которые он ворнинги AP> повыдавал) - после прошивки контроллер вообще не стартовал??

Вот 2.26 - точно в морг, багов там было не меряно. Стабильная версия была

2.28.
Reply to
Askold Volkov

Fri Dec 10 2004 12:14, Askold Volkov wrote to Aleksandr Popruga:

AP>> IAR C/EC++ Compiler for AVR AP>> 3.10C/W32 [Evaluation] (3.10.3.3) - кряканый

AP>> При достижении проектом некоторого размера (исходников ~130КБ) начались AP>> очень странные глюки при использовании в оптимизации "кластеризация AP>> переменных". AV> Вряд ли много кто пользуется этой версией, так что достоверно ответить AV> затруднительно. Hо раз текущая версия уже 3.20D, то очевидно, что ошибки AV> в предыдущих версиях были. У меня объем исходников 600кб и на v3.20C при AV> максимальной оптимизации глюков пока не замечено.

Попробовал на 3.20C собрать проект на ~800kb исходников - сразу же налетел на баги. Компилер иногда забывает что SFRы в extended I/O space являются volatile. Притом что 2.28A собирает все нормально.

AV> Вот 2.26 - точно в морг, багов там было не меряно.

Помню ровно один баг - в сложных функциях иногда "терялись" автопеременные. Обьявляешь как static - все нормально...

VLV

"Evil will prevail because good is dumb" (c) Dart Weider

Reply to
Vladimir Vassilevsky

Привет Askold!

10 Дек 04 13:14, Askold Volkov -> Aleksandr Popruga:

AP>> При достижении проектом некоторого размера (исходников ~130КБ) AP>> начались очень странные глюки при использовании в оптимизации AP>> "кластеризация переменных". Это у всех так, или у меня всетаки с AP>> проектом чево-то нето???

AV> Вряд ли много кто пользуется этой версией, так что достоверно ответить AV> затруднительно. Hо раз текущая версия уже 3.20D, то очевидно, что AV> ошибки в предыдущих версиях были. У меня объем исходников 600кб и на AV> v3.20C при максимальной оптимизации глюков пока не замечено.

А у тебя "ознакомительная" версия? Может ли быть глюки именно в ознакомительных версиях?

Aleksandr

... Годовых колец много, а пень пнем.

Reply to
Aleksandr Popruga

Привет Vladimir!

10 Дек 04 17:55, Vladimir Vassilevsky -> Askold Volkov:

VV> Попробовал на 3.20C собрать проект на ~800kb исходников - сразу же

А сколько кода получается из 800 кил исходников??? У меня из 130 - 13.5 с крос-кол оптимизацией и почти 16 без нее...

VV> налетел на баги. Компилер иногда забывает что SFRы в extended I/O VV> space являются volatile. Притом что 2.28A собирает все нормально.

А не подскажешь места, где можно его (2.28A) утянуть?

Aleksandr

... Годовых колец много, а пень пнем.

Reply to
Aleksandr Popruga

Всем привет!

Vladimir Vassilevsky писал к Askold Volkov Fri, 10 Dec 2004 17:55:53 +0300:

VV> Попробовал на 3.20C собрать проект на ~800kb исходников - сразу же VV> налетелна баги. Компилер иногда забывает что SFRы в extended I/O space VV> являются volatile. Притом что 2.28A собирает все нормально.

Тогда тебя спасет 3.20D - там как раз этот баг исправлен.

Reply to
Askold Volkov

Всем привет!

Aleksandr Popruga писал к Askold Volkov Fri, 10 Dec 2004 21:49:01 +0300:

AP> А у тебя "ознакомительная" версия? Может ли быть глюки именно в AP> ознакомительных версиях?

Никакой разницы между ознакомительными и полными версиями нет.

Reply to
Askold Volkov

Привет Askold!

11 Дек 04 15:02, Askold Volkov -> Vladimir Vassilevsky:

VV>> Попробовал на 3.20C собрать проект на ~800kb исходников - сразу VV>> же налетелна баги. Компилер иногда забывает что SFRы в extended VV>> I/O space являются volatile. Притом что 2.28A собирает все VV>> нормально.

AV> Тогда тебя спасет 3.20D - там как раз этот баг исправлен.

А где его брать? Hа

formatting link
сказано (было в пятницу) что текущая версия

3.20С...

Aleksandr

... Hельзя yпасть только с пола.

Reply to
Aleksandr Popruga

VV>> Попробовал на 3.20C собрать проект на ~800kb исходников - сразу же AP> А сколько кода получается из 800 кил исходников??? У меня из 130 - 13.5 с AP> крос-кол оптимизацией и почти 16 без нее...

Интересно соотношение размера исходника (на C) к размеру двоичного файла для разных платформ. У x51 получается раза в 2 больше чем у AVR, примерно. А у кого ещё как?

Reply to
Kirill Frolov

Sun Dec 12 2004 20:16, Kirill Frolov wrote to Aleksandr Popruga:

VV>>> Попробовал на 3.20C собрать проект на ~800kb исходников AP>> А сколько кода получается из 800 кил исходников??? У меня из 130 - 13.5 AP>> с крос-кол оптимизацией и почти 16 без нее... Трудно сказать, т.к. много #ifdef и данных. M128 занята на 125 килобайт. В общем, для IAR и AVR чисто по коду получается ~10% от размера исходника. KF> Интересно соотношение размера исходника (на C) к размеру двоичного KF> файла для разных платформ.

Пока все помещается в короткие обращения, примерно одинаково для процессоров одного класса: AVR, HC12, x51, PIC и пр.

KF> У x51 получается раза в 2 больше чем у AVR,

Huge модель, много пересылок?

KF> А у кого ещё как?

При решении контроллерных задач на DSP код получается раза в четыре более рыхлый, чем на обычных контроллерах. С точностью до наоборот при DSPшных задачах на микроконтроллерах. VLV

"Evil will prevail because good is dumb" (c) Dart Weider

Reply to
Vladimir Vassilevsky

Всем привет!

Aleksandr Popruga писал к Askold Volkov 12.12.2004:

AP> А где его брать? Hа

formatting link
сказано (было в пятницу) что текущая AP> версия 3.20С...

Апдейт (там всего один файл) можно взять там же, где все краки лежат:

formatting link
ru_embedded00 pass: sobaka

Reply to
Askold Volkov

Привет Askold!

14 Дек 04 07:50, Askold Volkov -> Aleksandr Popruga:

AP>> А где его брать? Hа

formatting link
сказано (было в пятницу) что AP>> текущая версия 3.20С...

AV> Апдейт (там всего один файл) можно взять там же, где все краки лежат:

AV>

formatting link
AV> id: ru_embedded00 AV> pass: sobaka

Ага, спасиба, уже и опробовал... Имхо даже по сравнению с С версией кое-чего подкрутили с оптимизациями.

ЗЫЖ А ктонить изучал разные виды оптимизаций и их взаимное влияние. Заметил, что на разных стадиях разработки проекта (тоесть при разном количестве сорцов) комбинации различных оптимизаций (те, которые галочками включаются и выключаются) дают разные результаты. Тоесть если все задействовать, код иногда больше, чем если какую-нибудю отключить...

Aleksandr

... Вот рыба была раньше - в воду без трусов не зайдешь!

Reply to
Aleksandr Popruga

Aleksandr, ты ещё здесь сидишь?

Вторник Декабрь 14 2004 19:34, Aleksandr Popruga wrote to Askold Volkov:

AP> ЗЫЖ А ктонить изучал разные виды оптимизаций и их взаимное влияние. AP> Заметил, что на разных стадиях разработки проекта (тоесть при разном AP> количестве сорцов) комбинации различных оптимизаций (те, которые AP> галочками включаются и выключаются) дают разные результаты. Тоесть AP> если все задействовать, код иногда больше, чем если какую-нибудю AP> отключить...

Hадеюсь, тебя не слишком удивит, что оптимизация по скорости выполнения влияет на размер кода строго противоположно, чем оптимизация по размеру кода?

Георгий

Reply to
George Shepelev

Георгий, здравствуйте.

Надеюсь, тебя сильно удивит, что в компиляторах IAR оптимизация по скорости дает более компактный код, чем оптимизация по размеру?

Сергей Борщ

Reply to
Sergey A. Borshch

"George Shepelev" <George snipped-for-privacy@f124.n.z2.fidonet.org>

сообщил/сообщила в новостях следующее: news:MSGID_2=3A461=2F124 snipped-for-privacy@fidonet.org...

кода? В кодогенераторе IAR 3.xx для AVR такой корреляции нет.

Денис.

Reply to
invalid unparseable

Fri, 17 Dec 2004 09:04:48 +0000 (UTC) Sergey A. Borshch wrote to George Shepelev:

AP>>> ЗЫЖ А ктонить изучал разные виды оптимизаций и их взаимное влияние. AP>>> Заметил, что на разных стадиях разработки проекта (тоесть при разном AP>>> количестве сорцов) комбинации различных оптимизаций (те, которые AP>>> галочками включаются и выключаются) дают разные результаты. Тоесть AP>>> если все задействовать, код иногда больше, чем если какую-нибудю AP>>> отключить...

SAB> Надеюсь, тебя сильно удивит, что в компиляторах IAR оптимизация по SAB> скорости дает более компактный код, чем оптимизация по размеру?

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

Reply to
Harry Zhurov

Hello, George Shepelev !

Иногда. Обычно как раз чем код меньше тем он и быстрее. Что ты знал бы, если бы умел программировать на ЯВУ и делал это.

С уважением, Дима Орлов.

Reply to
Dima Orlov

Fri Dec 17 2004 11:30, Harry Zhurov wrote to Sergey A. Borshch:

SAB>> Hадеюсь, тебя сильно удивит, что в компиляторах IAR оптимизация по SAB>> скорости дает более компактный код, чем оптимизация по размеру? HZ> Это так, пока размер не превышает какой-то предел. Hа больших HZ> проектах (десятки килобайт) оптимизация по размеру дает заметный выигрыш.

Сильная сторона IAR AVR - cross-call оптимизация, которая вообще-то на размер, а не на скорость.

VLV

"Evil will prevail because good is dumb" (c) Dart Weider

Reply to
Vladimir Vassilevsky

DO> Иногда. Обычно как раз чем код меньше тем он и быстрее. Что ты знал бы, DO> если бы DO> умел программировать на ЯВУ и делал это.

Типичный пример оптимизации switch-case -- выбор адреса перехода по таблице. Какой бывает получается размер, сам понимаешь...

Reply to
Kirill Frolov

Hello, Kirill Frolov !

Типично, это не пример оптимизации, а пример задаваемой прагмой/опцией командной строки реализации.

С уважением, Дима Орлов.

Reply to
Dima Orlov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.