Глюки IAR C for AVR 3.10C - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
Глюки IAR C for AVR 3.10C

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


Пятница Декабрь 17 2004 12:34, Dima Orlov wrote to George Shepelev:

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

 Естественно, раздувание кода ненужным обрамлением и "пустышками" скорости
не добавляет ;)

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

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

 А с наездами, плиз, куда-нибудь в более другое место!



                                                   Георгий


Глюки IAR C for AVR 3.10C
Hello, George Shepelev !

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

 >  DO> Иногда. Обычно как раз чем код меньше тем он и быстрее.

 >  Естественно, раздувание кода ненужным обрамлением и "пустышками"
 > скорости не добавляет ;)


Естественно, что ты опять трепешься о том, чего не знаешь.

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

 >  Регулярно пишу программы на Паскале, каждый раз убеждаюсь, что

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

 > аналогичные
 > вещи на ассемблере получаются меньше и быстрее. А также прекрасно знаю, как

Жора, ну что ты можешь прекрано знать?

 > при необходимости ускорить работу критичной части кода, увеличив
 > его размер.

Укажи опции оптимизации используемого тобой _компилятора_, приводящие к
подобному эффекту, или кончай трындеть не по делу (а лучше сразу кончай -
надоело). Как оптимизировать _алгоритмы_ тут и без тебя знают, а речь идет об
оптимизации кода компилятором, если до тебя еще не дошло, Жора.

 >  А с наездами, плиз, куда-нибудь в более другое место!

Вот и вали.

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


Глюки IAR C for AVR 3.10C
Hello Dima.

19 Dec 04 12:48, you wrote to George Shepelev:

 >> при необходимости ускорить работу критичной части кода, увеличив
 >> его размер.

 DO> Укажи опции оптимизации используемого тобой _компилятора_, приводящие
 DO> к подобному эффекту, или кончай трындеть не по делу (а лучше сразу
 DO> кончай - надоело). Как оптимизировать _алгоритмы_ тут и без тебя
 DO> знают, а речь идет об оптимизации кода компилятором, если до тебя еще
 DO> не дошло, Жора.

 Чего ты орешь, как больной слон ? Тривиальный Loop Unrolling, например..
 Первая ссылка с гугля:
 http://users.chariot.net.au/~matty/ultra/optcat/Loop_Unrolling.html


Dmitry


Глюки IAR C for AVR 3.10C
Hello, Dmitry Lyokhin !

 >>> при необходимости ускорить работу критичной части кода, увеличив
 >>> его размер.

 >  DO> Укажи опции оптимизации используемого тобой _компилятора_, приводящие
 >  DO> к подобному эффекту, или кончай трындеть не по делу (а лучше сразу
 >  DO> кончай - надоело). Как оптимизировать _алгоритмы_ тут и без тебя
 >  DO> знают, а речь идет об оптимизации кода компилятором, если до тебя еще
 >  DO> не дошло, Жора.

 >  Чего ты орешь, как больной слон ? Тривиальный Loop Unrolling,
 > например..
 >  Первая ссылка с гугля:
 >  http://users.chariot.net.au/~matty/ultra/optcat/Loop_Unrolling.html

Ты тоже читать не умеешь и испытываешь проблемы с пониманием русского языка? Я
не ссылку с гугля, а конкретные опции конкретного компилятора просил. И не
потому что не знаю про разворачивание циклов или не умею в гугле искать, а
потому что _опыт_ использования компиляторов для разных восьмиразрядных
микроконтроллеров (в том числе и IAR в том числе и для AVR) показывает, что
меньший сгенерированный код как правило и быстрей. И когда всякого рода
"теоретики" начинают молоть чушь в ответ на вполне практический вопрос, таки
хочется орать как больной слон, бо задолбало уже. Кстати раскрутка цикла
запросто может дать не только более быстрый, но и существенно более короткий
код, если при этом адресация по параметру цикла заменяется статической, а
эффективной аппаратной реализации косвенной адресации в контроллере нет.
Hапример PIC16. Только вот циклы прийдется ручками раскручивать, сам компилятор
этого делать не умеет. Так что передавай привет гуглу...



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


Глюки IAR C for AVR 3.10C
    Всем привет!

Dima Orlov писал к Dmitry Lyokhin 19.12.2004:

 DO> гугле искать, а потому что _опыт_ использования компиляторов для разных
 DO> восьмиразрядных микроконтроллеров (в том числе и IAR в том числе и для
 DO> AVR) показывает, что меньший сгенерированный код как правило и быстрей.

Есть в IARе такие опции - "cross call optimization" и "always do cross call
optimization" - дык вот они однозначно делают код короче и медленнее. Причем
последняя опция стоит в IARе особняком и не связана с выбранным типом
оптимизации, поэтому многие включают ее не разобравшись, а потом удивляются
чего это у них такая плохая оптимизация по скорости. А делает эта
оптимизация вот что - выделяет одинаковые куски из разных мест программы и
заменяет их обращением к одной общей подпрограмме.

--
Аскольд Волков, Новосибирск. http://www.inp.nsk.su/~volkov/


Re: Глюки IAR C for AVR 3.10C

                  Здравствуй, Askold!


 AV> Есть в IARе такие опции - "cross call optimization" и "always do cross
 AV> call optimization" - дык вот они однозначно делают код короче и медленнее.
 AV> Причем последняя опция стоит в IARе особняком и не связана с выбранным
 AV> типом оптимизации, поэтому многие включают ее не разобравшись, а потом
 AV> удивляются чего это у них такая плохая оптимизация по скорости. А делает
 AV> эта оптимизация вот что - выделяет одинаковые куски из разных мест
 AV> программы и заменяет их обращением к одной общей подпрограмме.

     И еще жрет стеки. Мешает при нехватке оперативной памяти.

                                              Успехов!
                                         До свидания. Sergey.


Re: Глюки IAR C for AVR 3.10C
Mon Dec 20 2004 11:14, Sergey Brylew wrote to Askold Volkov:

 
 AV>> Есть в IARе такие опции - "cross call optimization" и "always do cross
 AV>> call optimization" - дык вот они однозначно делают код короче и
 AV>> медленнее.
 SB> И еще жрет стеки. Мешает при нехватке оперативной памяти.

 А кстати, можно ли в том же IAR AVR посмотреть максимальную глубину
 вложенности обеих стеков?

 VLV
 

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


Re: Глюки IAR C for AVR 3.10C

                  Здравствуй, Vladimir!

 VV>  А кстати, можно ли в том же IAR AVR посмотреть максимальную глубину
 VV>  вложенности обеих стеков?

      Так в конце листинга (.lst) если соответствующие опции заданы.
По каждой функции вместе со вложенными функциями и RSTACK и CSTACK в
виде таблички. Hе указывается только использование scratch регистров.
Они по документации IAR тоже как-бы стеком считаются. И тоже страдают при
дурацкой оптимизации. Также, как и общее быстродействие. В общем, имхо
cross-call оптимизация имеет смысл только, если памяти программ не хватает.
Да, это все для IAR C 2.28. Я на другие пока не переходил.

ЗЫЖ При использовании вложенных прерываний эту табличку использования
стеков лучше не смотреть ;))

                                              Успехов!
                                         До свидания. Sergey.


Re: Глюки IAR C for AVR 3.10C

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


Пятница Декабрь 17 2004 12:04, Sergey A. Borshch wrote to George Shepelev:

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

 Hе сильно. Это попросту означает, что оптимизация по быстродействию
в компиляторе IAR сделана откровенно халтурно. Метод размена объёма
на быстродействие известен десятки лет и никем ещё не отменён.


                                                   Георгий


Re: Глюки IAR C for AVR 3.10C

Quoted text here. Click to load it

Георгий!
Рискую нарваться на гнев следящих за порядком,

Quoted text here. Click to load it
но шел бы ты нах.. с такими ^^^^^^^^^^^^^^^^^^^ заявлениями.


  Без уважения
   Сергей Борщ

--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru

Site Timeline