реклама на сайте
подробности

 
 
6 страниц V  « < 3 4 5 6 >  
Reply to this topicStart new topic
> Какую среду разработки Вы используете?
Какую среду разработки Вы преимущественно используете для своих проектов, и почему?
среда разработки (компилятор/транслятор)
AVR-Studio (atmel-avr-asm) [ 43 ] ** [17.27%]
AVR-Studio + gcc-plugins [ 12 ] ** [4.82%]
IAR-EWAVR преимуществунно (asm) [ 0 ] ** [0.00%]
IAR-EWAVR преимущественно ( C ) [ 79 ] ** [31.73%]
WinAvr (gcc) [ 33 ] ** [13.25%]
CodeVision [ 52 ] ** [20.88%]
ImageCraft-C [ 9 ] ** [3.61%]
E-LAB pascal [ 1 ] ** [0.40%]
Alhorithm Builder [ 7 ] ** [2.81%]
AVR-Basic [ 2 ] ** [0.80%]
другую [ 11 ] ** [4.42%]
Всего голосов: 249
Гости не могут голосовать 
beer_warrior
сообщение May 24 2006, 13:51
Сообщение #61


Профессионал
*****

Группа: Свой
Сообщений: 1 065
Регистрация: 8-10-05
Из: Kiev, UA
Пользователь №: 9 380



2 DXP
Все верно, однако...
Не вижу я большой в этом беды.
Например, если передавать в функцию больше 3 параметров... может стоит в в консерватории, что-то подправить?
Ну да в *printf(), ну так сколько об этом говорено.
С другой стороны ldd/std займет указатель - выигрыш во времени, проигрыш в регистрах. Вы уверены, что вам этот регистр в функции не понадобится?
Все это небольшое преимущество (?) убьеться на корню просто наличием каких-то левых переменных, лишними вызвами функций итп.
Чем мне нравиться gcc - не прощает небрежности, держит в тонусе, IAR же из-за своего ума позволяет расслабляться, что может стать источником трудноуловимых ошибок. Но это, как я уже говорил, дело вкуса.


--------------------
Вони шукають те, чого нема,
Щоб довести, що його не існує.
Go to the top of the page
 
+Quote Post
defunct
сообщение May 24 2006, 14:44
Сообщение #62


кекс
******

Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326



Цитата(beer_warrior @ May 24 2006, 16:51) *
2 DXP
Все верно, однако...
Не вижу я большой в этом беды.
Например, если передавать в функцию больше 3 параметров... может стоит в в консерватории, что-то подправить?
Ну да в *printf(), ну так сколько об этом говорено.
С другой стороны ldd/std займет указатель - выигрыш во времени, проигрыш в регистрах. Вы уверены, что вам этот регистр в функции не понадобится?
Все это небольшое преимущество (?) убьеться на корню просто наличием каких-то левых переменных, лишними вызвами функций итп.
Чем мне нравиться gcc - не прощает небрежности, держит в тонусе, IAR же из-за своего ума позволяет расслабляться, что может стать источником трудноуловимых ошибок. Но это, как я уже говорил, дело вкуса.

Абсолютно согласнен со сказанным. Еще неизвестно что полезней. Более строгий стиль написания или чрезмерно умный компилятор? А эффективность сгенерированного кода может с успехом быть выше на gcc, тому есть подтверждение даже на этом форуме - пару месяцев назад пробегавшая здесь ветка о USB драйвере для AVR.


На мой взгляд, единственное неоспоримое преимущество IAR состоит во встроенной поддержке 64-битной арифметики с плавающей запятой.
Go to the top of the page
 
+Quote Post
beer_warrior
сообщение May 24 2006, 16:12
Сообщение #63


Профессионал
*****

Группа: Свой
Сообщений: 1 065
Регистрация: 8-10-05
Из: Kiev, UA
Пользователь №: 9 380



Цитата
На мой взгляд, единственное неоспоримое преимущество IAR состоит во встроенной поддержке 64-битной арифметики с плавающей запятой.

Добавлю, автоматическая генерация lpm, при модификаторе _flash,
в gcc надо с этим шаманить.


--------------------
Вони шукають те, чого нема,
Щоб довести, що його не існує.
Go to the top of the page
 
+Quote Post
dxp
сообщение May 25 2006, 04:33
Сообщение #64


Adept
******

Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343



Цитата(beer_warrior @ May 24 2006, 20:51) *
2 DXP
Все верно, однако...
Не вижу я большой в этом беды.

А я не утверждаю, что в этом какая-то большая беда. Я лишь спорил с утверждением, что AVR-GCC генерит более компактный и быстрый код нежели IAR. Это совсем неверно, за IAR'ом приоритет. Надеюсь, Вы не спорите с этим тезисом?

В свое время оценивал качество кодогенерации IAR, AVR-GCC и ImageCraft. На первом месте IAR, на втором AVR-GCC, на последнем оказался ImageCraft. Еще народ сравнивал с CodeVision, утверждают, что этот соответствет ImageCraft'у. Таким образом, из распространенных компиляторов для AVR по качеству кодогенерации AVR-GCC прочно удерживает второе место. Почетное второе место - некоммерческому проекту тут с IAR'ом тягаться сложно.

Цитата(beer_warrior @ May 24 2006, 20:51) *
Например, если передавать в функцию больше 3 параметров... может стоит в в консерватории, что-то подправить?
Ну да в *printf(), ну так сколько об этом говорено.
С другой стороны ldd/std займет указатель - выигрыш во времени, проигрыш в регистрах. Вы уверены, что вам этот регистр в функции не понадобится?

Речь идет не только и не столько о передаче аргументов через стек, сколько об использовании локальных объектов внутри функции. Вот, например, объявлен внутри функции пяток переменных - пара интов, один флоат, мелкая структурка-враппер, которую возвращает одна из вызываемых функций и/или юнион. Регистров на это не хватит - они и так для работы нужны, поэтому разместится это в стеке. И тут нужна эффективная работа со стеком. В IAR'е все прозрачно - Y-pointer непосредственно все это адресует. В случае же avr-gcc компилятор будет производить ту самую подготовку стекового кадра (stack frame) - копирование в критической секции значения SP в Y, модификация SP, чтобы он указывал за пределы выделенного стекового кадра (чтобы было куда адреса возвратов складывать и оно не перемешалось с данными выделенного стекового кадра). Похожую операцию делает, например, комплитор для Blackfin'а, но у этого проца есть специальная инструкция подготовки стекового кадра - link N (где N - размер кадра), для нее есть парная инструкция unlink. А AVR-GCC эти вещи делает сам. Оверхед налицо. И порой не мелкий.

Цитата(beer_warrior @ May 24 2006, 20:51) *
Все это небольшое преимущество (?) убьеться на корню просто наличием каких-то левых переменных, лишними вызвами функций итп.
Чем мне нравиться gcc - не прощает небрежности, держит в тонусе, IAR же из-за своего ума позволяет расслабляться, что может стать источником трудноуловимых ошибок. Но это, как я уже говорил, дело вкуса.

Хороший и высококачественный инструмент - совсем не повод писать безобразный и горбатый код. Код всегда надо писать идеологически правильный, чтобы не было сюрпризов. И еще надо знать "повадки" компилятора, чтобы добиваться устойчивого по предсказуемости результата. Т.ч. тезис "gcc - не прощает небрежности, держит в тонусе, IAR же из-за своего ума позволяет расслабляться, что может стать источником трудноуловимых ошибок" мне не понятен. Если писать криво, с хаками, использовать код, приводящий к неопределенному поведению и т.д., то при любом компиляторе будет плохо. Если писать грамотно, с пониманием требований языка и особенностей реализации, то при любом компиляторе будет хорошо. Только с IAR'ом будет лучше, чем с AVR-GCC. Насколько лучше и кому это надо - это другой вопрос.


--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
Go to the top of the page
 
+Quote Post
beer_warrior
сообщение May 25 2006, 05:53
Сообщение #65


Профессионал
*****

Группа: Свой
Сообщений: 1 065
Регистрация: 8-10-05
Из: Kiev, UA
Пользователь №: 9 380



Цитата
Я лишь спорил с утверждением, что AVR-GCC генерит более компактный и быстрый код нежели IAR. Это совсем неверно, за IAR'ом приоритет. Надеюсь, Вы не спорите с этим тезисом?

Спорю. Не всегда.
Мне очень часто приходиться переносить код с других компиляторов под gcc, и работу и либы, так вот - после всего этого CV и ImageCraft я за серьезные продукты не считаю. С IARом же бабушка надвое сказала - может быть выигрыш и в ту и в другую сторону - зависит от конкретного кода. defunct уже привел пример с USB драйвером. Я к сожалению примера привести не могу, но как только напорюсь на подобный случай обязательно задокументирую и приведу. Вместе разберем на глазах у общественности.
Цитата
Если писать криво, с хаками, использовать код, приводящий к неопределенному поведению и т.д., то при любом компиляторе будет плохо. Если писать грамотно, с пониманием требований языка и особенностей реализации, то при любом компиляторе будет хорошо.

Дело в том, что gcc в 90% случаев просто не даст собрать кривой код.
По умолчанию он чрезвычайно педантичен. Когда я пару лет назад перескакивал на него с IAR, волком выл - нихрена не работало. Все время в листинг приходилось лазить. Зато через год почувствовал насколько я стал лучше писать. В общем это как ручное переключение передач и коробка-автомат - можно спорить до хрипоты, но налицо просто два разных подхода, дело вкуса.


--------------------
Вони шукають те, чого нема,
Щоб довести, що його не існує.
Go to the top of the page
 
+Quote Post
dxp
сообщение May 25 2006, 07:23
Сообщение #66


Adept
******

Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343



Цитата(beer_warrior @ May 25 2006, 12:53) *
Цитата
Я лишь спорил с утверждением, что AVR-GCC генерит более компактный и быстрый код нежели IAR. Это совсем неверно, за IAR'ом приоритет. Надеюсь, Вы не спорите с этим тезисом?

Спорю. Не всегда.
Мне очень часто приходиться переносить код с других компиляторов под gcc, и работу и либы, так вот - после всего этого CV и ImageCraft я за серьезные продукты не считаю.

Если попереносить код с gcc на другие компиляторы, там тоже такого понавылазит, что мало не покажется - там одних gcc'шных расширений до и больше. И будут говорить (и говорят - почитайте архивы su.c-cpp), что gcc дерьмо, писанный в нем код нихрена нигде без доработки напильником не работает. А на деле все упирается в элементарную портабельность. Портабельный код работает везде.

Цитата(beer_warrior @ May 25 2006, 12:53) *
С IARом же бабушка надвое сказала - может быть выигрыш и в ту и в другую сторону - зависит от конкретного кода. defunct уже привел пример с USB драйвером.

И что? Кто-то написал горбатый код и это приводится в пример. Возьмите какой-нибудь тест, который используется, например, для тестирования производительности разных процессоров, и сравните.

Цитата(beer_warrior @ May 25 2006, 12:53) *
Дело в том, что gcc в 90% случаев просто не даст собрать кривой код.

smile.gif Улыбаете. Да куда ж он денется. Приведите пример кривого кода, который компиляется, например, в IAR'е и не компиляется в GCC?

Цитата(beer_warrior @ May 25 2006, 12:53) *
По умолчанию он чрезвычайно педантичен. Когда я пару лет назад перескакивал на него с IAR, волком выл - нихрена не работало. Все время в листинг приходилось лазить. Зато через год почувствовал насколько я стал лучше писать. В общем это как ручное переключение передач и коробка-автомат - можно спорить до хрипоты, но налицо просто два разных подхода, дело вкуса.

Заблуждение. Я когда начинал писать на том же IAR'е, тоже постоянно в листинг смотрел (благо, листинг у него человеческий, а не как у gcc), и частенько находил там причину не того поведения, которого ожидал. А главная причина этого была в том, что в те времена сам еще тот же С толком не знал. Когда поработал годок-другой, когда скилл подрос, так и писать сразу хорошо стало получаться. Потом то, что пробовал на gcc, все сразу получалось без вопросов. Основные вопросы при знакомстве с gcc были - это дурацкая документация (по сравнению с коммерческими продуктами), дурацкий, запутанный, загроможденный формат файла листинга (после IAR'а так вообще ломало, благо ситуацию можно было несколько исправить применением sed'ового скрипта для удаления лишнего и форматирования оставшегося), оригинальный подход при задании сегментов линкеру - когда там все разные адресные пространства отмаплены на одно, и другие более мелкие вопросы. Но с кодогенерацией и работоспособностью кода никаких проблем уже не было.

Т.ч. не надо тут сравнений про коробки передач, мимо кассы они. Горбатый код на IAR'е точно так же не работает. Посмотрите, сколько вопросов про IAR тут задают, вечно у кого-то что-то не работает (у новичков, по большей части, которые просто еще не научились, и пишут тот самый кривой код). Про gcc вопросов на порядок меньше - косвенно это указывает совсем на обратное, утверждаемому Вами. Конечно, это объясняется в первую очередь, что пользователей gcc гораздо меньше, а новички по больше части западают на более дружественный и простой в основении IAR. Но при прочих равных компиляторы эти по требовательности к качеству исходного кода примерно равны и определяется это следованием Стандарту - любой компилятор, выполняющий требования Стандарта, будет примерно одинаково реагировать на кривой код - либо ругаться на ошибки, либо генерировать код с неопределенным поведением.


--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
Go to the top of the page
 
+Quote Post
zltigo
сообщение May 25 2006, 08:07
Сообщение #67


Гуру
******

Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244



Цитата(dxp @ May 25 2006, 10:23) *
...любой компилятор, выполняющий требования Стандарта, будет примерно одинаково реагировать на кривой код - либо ругаться на ошибки, либо генерировать код с неопределенным поведением.

Именно так дело и обстоит - могу свидетельствовать после многолетней работы на разных платформах под разными компиляторами.
Ну а сравнивать реакцию на 'кривой' код можно только при всех активизированых warnigs и remarks.
Практически весь сыр-бор разгорается из-за какого-то проекта с задваленными warnings и нюансами
трактовки warning/error конкретным компилятором.


--------------------
Feci, quod potui, faciant meliora potentes
Go to the top of the page
 
+Quote Post
_Bill
сообщение May 25 2006, 08:53
Сообщение #68


Местный
***

Группа: Участник
Сообщений: 416
Регистрация: 18-04-06
Из: Челябинск
Пользователь №: 16 219



Цитата(beer_warrior @ May 25 2006, 11:41) *
Впрочем не люблю быть голословным, обязательно выловлю примеры из практики и тогда мы вернемся к этому разговору.

Это было бы замечательно!
Go to the top of the page
 
+Quote Post
dxp
сообщение May 25 2006, 12:23
Сообщение #69


Adept
******

Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343



Цитата([banned] @ May 25 2006, 17:55) *
1001-й "бенч мак" намечается ...

вот такой тест покатит ?

http://www.atmanecl.net/EnglishSite/CCCE.htm



=======

это кстати IDE на основе GCC. С встроенным генератором начального кода.

и CVAVR там не плохо смотрится.

Там откровенный гон приведен. IAR мне выдал 118 байт при оптимизации по скорости и 110 - по размеру.

IAR
Командная строка (по скорости):
%IAR%\%AVR%\bin\iccavr.exe slon.cpp -lC slon.lst -e --cpu=m16 -ms -s9 -r -I%IAR%\%AVR%\inc -I%IAR%\%AVR%\inc\dlib --diag_suppress=Pe951

Вывод компилятора:
IAR Atmel AVR C/C++ Compiler V4.12A/W32, Evaluation Version
Copyright 1996-2005 IAR Systems. All rights reserved.

118 bytes of CODE memory
0 bytes of DATA memory (+ 3 bytes shared)

Errors: none
Warnings: none


Командная строка (по размеру):
%IAR%\%AVR%\bin\iccavr.exe slon.cpp -lC slon.lst -e --cpu=m16 -ms -z9 -r -I%IAR%\%AVR%\inc -I%IAR%\%AVR%\inc\dlib --diag_suppress=Pe951

Вывод компилятора:
IAR Atmel AVR C/C++ Compiler V4.12A/W32, Evaluation Version
Copyright 1996-2005 IAR Systems. All rights reserved.

110 bytes of CODE memory
0 bytes of DATA memory (+ 3 bytes shared)

Errors: none
Warnings: none


WinAVR 20060421
Командная строка:
avr-c++.exe -c -mmcu=atmega16 -g -O3 -Wa,-adhlms=slon.lst slon.cpp

Поскольку компилятор не утруждается выводом статистики по размерам использованных данных и кода ни при выводе, ни в листинге, то приходится использовать утилитку:

avr-size.exe slon.o

Ее вывод:
Код
   text    data     bss     dec     hex filename
    258       0       0     258     102 slon.o

Насколько я знаком с gcc, секция text - это и есть код. Т.е. 258 байт. Что-то много. Оптимизация максимальная.

Снижаем оптимизацию до O2 получаем:

Код
text    data     bss     dec     hex filename
130       0       0     130      82 slon.o


Намного лучше. Другие виды оптимизации дают тот же результат. Без оптимизации:

Код
   text    data     bss     dec     hex filename
    310       0       0     310     136 slon.o

Совсем плохо. Вывод - работать, видимо, надо с O2. Но такой дикий разброс - в два раза выглядит очень странно! Зато логично выглядит замечание коллеги beer_warrior'а, что с gcc надо держать ухо востро - на IAR'е я выставил максимальную оптимизацию и забыл про проблемы - получаю всегда самый лучший код. А за этим надо следить - как бы он чего не напакостил. Вряд ли это обстоятельство можно отнести к достоинствам компилятора.

118/130 - 10%
110/130 - 15%

Где-то так оно и есть. Хотя по такому мелкому тесту судить, конечно, нельзя.

Цитата(beer_warrior @ May 25 2006, 18:20) *
Цитата
Т.е. Вы - укротитель кода, мегаалгоритмист, который за счет крутого стиля сделает любого другого даже на более слабом инстументе?
Ага, а я - недоделок гонорной, который прогу перенести с одной платформы на другую не в состоянии. Мерси за оценку. smile.gif

Зря вы так.

Прошу прощения за некоторую резкость, но выглядело это именно так.

Цитата(beer_warrior @ May 25 2006, 18:20) *
По простому - если я знаю, что мой компилятор в каких-то моментах слаб, я избегаю таких моментов, если знаю что силен я такое решение предпочту. Все зависит от кода.
Например при работе с флэшью gcc сильно проигрывает, и если такого кода много тут ничего не поделаешь.Если каким-то образом это можно обойти, тогда догоняем.

Это похоже на "моя машина плохо берет подъемы, поэтому в подъемы я стараюсь не ездить". smile.gif


--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
Go to the top of the page
 
+Quote Post
Старый Бабай
сообщение May 25 2006, 12:48
Сообщение #70


Частый гость
**

Группа: Свой
Сообщений: 104
Регистрация: 5-12-05
Из: Екатеринбург
Пользователь №: 11 823



Пользую GCC в связке с AVRStudio
Go to the top of the page
 
+Quote Post
beer_warrior
сообщение May 25 2006, 13:57
Сообщение #71


Профессионал
*****

Группа: Свой
Сообщений: 1 065
Регистрация: 8-10-05
Из: Kiev, UA
Пользователь №: 9 380



quote]Совсем плохо. Вывод - работать, видимо, надо с O2. Но такой дикий разброс - в два раза выглядит очень странно![/quote]

# Optimization level, can be [0, 1, 2, 3, s].
# 0 = turn off optimization. s = optimize for size.
# (Note: 3 is not always the best optimization level. See avr-libc FAQ.)[

So generally, it seems -Os -mcall-prologues is the most universal "best" optimization level. Only applications that need to get the last few percent of speed benefit from using -O3.


--------------------
Вони шукають те, чого нема,
Щоб довести, що його не існує.
Go to the top of the page
 
+Quote Post
Nanobyte
сообщение May 25 2006, 14:32
Сообщение #72


За битами по регистрам гоняюсь
***

Группа: Свой
Сообщений: 457
Регистрация: 24-04-06
Из: Таганрог
Пользователь №: 16 446



Большинство проектов выполнял на ASM, из плюсов - максимальное быстродействие, полный контроль над МК, отсутствие проблем с постоянным поиском новых версий компиляторов. Из минусов - бОльший объём исходных текстов. Отладка проводится в основном на живом железе, иногда, в сложных случаях, использую Studio. Для работы с текстом пользуюсь FAR, с расцвечиванием для AVR. Встроенный редактор Studio кривоват (IMHO).


--------------------
Курсор влево, курсор вправо - считается хакерством. FORMAT C: производится без предупреждения
Go to the top of the page
 
+Quote Post
defunct
сообщение May 25 2006, 15:23
Сообщение #73


кекс
******

Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326



Цитата
> при оптимизации по скорости 182 слова.

182*2 = 364 байта.
что более чем втрое больше кода, сгенерированного IAR'ом и
почти втрое больше кода сгенерированного gcc (-02 не лучшая оптимизация).

Для теста скомпилировал один из своих проектов с большим числом мат. расчетов в IAR без оптимизации (BEST DEBUG) с поддержкой 64 бит double объем HEX файла - 11 555 байт
ICC с оптимизацией (естественно с 32 бит double) - 21 702 байт
Go to the top of the page
 
+Quote Post
SasaVitebsk
сообщение May 25 2006, 19:35
Сообщение #74


Гуру
******

Группа: Свой
Сообщений: 2 712
Регистрация: 28-11-05
Из: Беларусь, Витебск, Строителей 18-4-220
Пользователь №: 11 521



По поводу компилятора. Попробовал переписать на ASM хороший кусок линейного кода IAR C (без использования сложной арифметики). Результат кропотливой оптимизации не превысил 35%. Некоторые куски компилируются в более оптимальный код!!!! Этого я не ожидал.

По поводу AVR123. Я считаю что Вы делаете нужное дело. Не страшно что есть ошибки! Не ошибается тот, кто ничего не делает! А вот рекламы надо поменьше. Все уже от неё устали и поэтому злятся. smile.gif Переключитесь на время на Точку Опоры. Там новичков побольше. Переговорите с webmasterom Точки Опоры может они Ваш курс включат в свои ссылки. И пожалуйста, не принимайте мои слова за критику, но моё мнение что навигации в Вашем курсе всётаки не хватает. Мало чайников найдётся чтобы запоем читать. А вот отдельные моменты, - это пожалуйста.

На окончательное мнение не претендую.
Go to the top of the page
 
+Quote Post
defunct
сообщение May 25 2006, 20:11
Сообщение #75


кекс
******

Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326



Цитата(SasaVitebsk @ May 25 2006, 21:41) *
А каким образом Вы NOP в проект на C подключали? Может в этом кроется ошибка?


asm("nop")?
Go to the top of the page
 
+Quote Post

6 страниц V  « < 3 4 5 6 >
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 25th July 2025 - 22:45
Рейтинг@Mail.ru


Страница сгенерированна за 0.01497 секунд с 7
ELECTRONIX ©2004-2016