Форум РадиоКот

ploop писал(а):Пруф есть?

google работает ?

Да работает, поэтому и говорю, что не всё так однозначно.
Ну вот, например, с хабра: http://habrahabr.ru/company/abbyy/blog/103447/

Что касается gcc и volatile, я смотрел примеры и наткнулся на проблему/решение.
Решение это memory barrier. Применяя его рядом с volatile получаем "все пашет".

Вот пруфлинк:
http://depni.sinp.msu.ru/~hatta/lpc.html
Там в середине статьи есть фраза "сильно глупеет" вот что бы не глупел и написан рецепт


Еще там есть фраза:
Благодаря усилиям фирмы CodeSourcery, в которой числится добрая половина всех основных разработчиков GCC, этот свободный компилятор поддерживает весь набор архитектур ARM7, в том числе и ARM7-TDMI-S, используемый в LPC2xxx.

Если калоши не вкусные, вы просто не умеете их готовить Для моих задач, возможностей stm32 не просто хватит...их раз пять хватит...значит даже если согласится, что gcc Г. (а я не думаю так), все равно он бесплатен и доков куча и проблем нет. Но думаю, если знать как прописать параметры gcc такой же инструмент как и все, просто как и все, с своими особенностями, которые надо знать.


Если подумать, то gcc это компилятор, собирающий ядро linux (со всеми извратами его, хинтами и финтами ушами), а оно по подсчетам стоит 4 млрд. долларов уже

Еще там про сей финт написано: Об нем написано в руководстве по gcc в разделе про встраиваемый ассемблер


Для бесплатных продуктов...требуется чтение документации больше чем для прочих. Дело тут не в том, что "они кривые", а в том, что они свободные...а значит любой желающий придумать и сделать финт ушами на 180 градусов (этих финтов просто больше чем у комеров), может это сделать и в документацию добавляется еще один пункт, который надо прочесть Это и есть главный недостаток свободного софта, растет в кучу сторон сразу...как сказано в одном из предыдущих постов "особенность разработки".

Какие вам ещё доказательства нужны - компилятор от производителя процессоров! Интеловцы сами-то знают как лучше оптимизить под их процы. И, главное - только под их процы. А gcc много под что умеет код генерить, соответственно основная масса оптимизаций, IMHO, это высокоуровневые оптимизации, которые особо не учитывают архитектуру проца (если вообще как-то учитывают, а интел наверняка это делает).
Интеловский компилер делает более быстрый код при векторизации вычислений (если он, компилер, смог разобраться в программе, чтобы сделать векторизацию, т.е. сгененрить код для MMX, SSE и т.д.).
Другая особенность, которую используют, это переупорядочивание команд процессора, чтобы эффективнее работало внеочередное исполнение и была более эффективная загрузка конвеера процессора. Для этого тоже надо знать особенности проца. В программах где нет возможностей для векторизации разрыв по скорости, скорее всего, незначительный.
Современный gcc, если мне не изменяет память, использует и то и другое (нет под рукой информации, точнее сказать не могу). Однако, не надо упускать из внимания, то что gcc многоплатформенный и у его разработчиков, наверняка, информации о проце меньше, чем у самого Интела. Тут как всегда - универсальное, но не самое эффективное, и, наоборот, специализированное и более эффективное.
Надо помнить, и то, с какими опция копилируется программа. Процентов 7-10, в среднем, можно получить при компиляции под конкретный проц тем же gcc, не просто с -O2 (инфа с форумов по gentoo linux ).
Пример бенчмарка на POV-Ray из теста компилеров на FineReader Engine for Linux уж точно не расходиться с предположением про векторизацию расчётного кода. Последняя картинка с бенчмарком показывает, что gcc не так уж и плох на обычном коде по сравнению с icc.

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

Холиварить gcc vs icc не вижу смысла - картина вполне логична. Дальше - на вкус и цвет....

Фух... ну и настрочил

К стати, вот нашёл про ARM-ы. Сравнение компиляторов.
2006 год, gcc 4.0 и другие
Это новее, 2008, gcc 4.1.1 и другие

И вот ещё сравнение Cortex-A8 и iAtom

Дык и я о том, всё настолько неоднозначно и зависит от огромного количества условий. Если дело доходит до выжимания из процессора всего, что можно (ресурсоёмкие вычисления, длительные по времени и т.д.) - то конечно, тут и компиляторы роль играют, и тонны документации на конкретную архитектуру придётся лопатить, и ассемблером не брезгуют. Но в подавляющем большинстве случаев это не нужно, и gcc нормально справляется.

Мне просто не нравятся категоричные заявления - это УГ, а это - конфетка.

Что бы закончить микрохоливар напишу вот, что:
С помощью утилиты stlink+Eclipse+CodeSourcery gcc, удалось запустить
в линуксе компиляцию и аппаратную отладку программы на stm32vldiscovery.

Вот шаблон проекта
https://github.com/h0rr0rrdrag0n/stm32v ... x-template
Вот статья по которой делал
http://robocraft.ru/blog/ARM/653.html

Важно: в eclipse надо в настройках Debug Configuration надо нажать "Select other..." и выбрать Standart launcher ....или как то так. В противном случае последняя версия плагина и эклипса gdb запустить не могут и он валится с ошибкой. Если сделать, все пашет как надо.

Диоды на плате я включил оба! Теперь можно и доки читать колупая по ходу дела

Да, я там даже зарегистрировался недавно, вопрос задавал.

Вот еще обзор тулчайнов
http://we.easyelectronics.ru/CADSoft/ob ... ast-1.html

ploop писал(а):

Я удивлюсь, елси есть хоть одна архитектура, под которую GCC не хуже среднего по больнице.

Чего? Хочешь сказать, что для x86 от тоже плохой код делает?

Очень плохой, особенно по размеру. Понятно, что размер на современных ПК некритичен, но, простите, если мелкомягкий компилятор на максимальной оптимизации по скорости даёт код, существенно меньший по длине, чем GCC при оптимизации по размеру...

Мне просто не нравятся категоричные заявления - это УГ, а это - конфетка.

Мне тоже Но именно по качеству кода GCC, увы, куда ближе к УГ...

3DRaven писал(а):Что касается gcc и volatile, я смотрел примеры и наткнулся на проблему/решение

Да я тоже нашёл решение методом тыка, но сам-то компилятор не становится от этого лучше. Ну не должно быть случаев, когда код генерируется неверный

Благодаря усилиям фирмы CodeSourcery, в которой числится добрая половина всех основных разработчиков GCC, этот свободный компилятор поддерживает весь набор архитектур ARM7, в том числе и ARM7-TDMI-S, используемый в LPC2xxx.

Ага, только, помнится, именно под ARMv4T компилятор что-то там неверно генерирует, если совместно используется ARM- и Thumb-код (сам не сталкивался, поскольку пишу главным образом на ассемблере; если очень интересно, могу покопаться и поискать). Кроме того, наткнулся на абсолютно неверную кодогенерацию (ассемблерный файл не транслировался вообще) для Thumb-2. Правда, тот исходник не сохранил, так что вряд ли смогу воспроизвести, да и исправили, надо полагать, столь явную ошибку уже...

gcc Г. (а я не думаю так), все равно он бесплатен и доков куча и проблем нет

Проблемы есть, просто их можно обходить.

Но думаю, если знать как прописать параметры gcc такой же инструмент как и все, просто как и все, с своими особенностями, которые надо знать

Ага. Вон, кейловский компоновщик они починили по моему баг-репорту, но испортили саму среду разработки, и она начала в некоторых случаях глючить Сейчас сидят, её чинят. (Похоже, у них практически никто на ассемблере ничего не пишет вообще, а я-то на нём, вот и ползут нестандартные баги; плюс я к ассемблерному коду прикомпоновываю адский, протранслированный GCC -- пожалуй, ещё менее стандартный случай ).

плюс я к ассемблерному коду прикомпоновываю адский, протранслированный GCC -- пожалуй, ещё менее стандартный случай

Таи и хочется сказать популярную фразу: "мсье знает толк..."

ploop писал(а):Таи и хочется сказать популярную фразу: "мсье знает толк..."

Ага Были б коммерческие компиляторы Ады под ARM -- купили бы, но найти не удалось, вот и пришлось столь извращённым способом-с...

Мне интересно, а зачем писать на ADA? Область применения какая?

Код на Аде при прочих равных много надёжнее, чем на Си, в силу надёжности самого языка: очень трудно допустить такую ошибку, которую пропустит компилятор (в Си подобные ошибки -- нормальное явление). По этой причине я Си вообще не пользуюсь, если нет крайней в этом нужды (лет 5 на нём писал, поскольку это было требование работодателя, но, к счастью, давно уже не там). На ПК основной инструмент -- Дельфи (Паскаль, конечно, менее надёжен, чем Ада, но зато есть нормальная среда разработки, да и тратить время на создание окошек не требуется, ну а эффективность компилятора... может, даже хуже, чем GCC, но на ПК у меня нет критичных в этом плане задач).

А область применения -- промышленная автоматизация. В частности, приборы контроля примесей в воде для электростанций, фармацевтики и прочей такой фигни. Но мой выбор не ею определяется, а именно достоинствами самого языка.

МитяРа писал(а): Так что там с потреблением, например у NXP?

Если собрался электричество экономить, для тебя новинка -))

"With the industry’s lowest active power consumption at 110 µA/MHz and reduced deep sleep current below 2 µA, the LPC1100XL has set a new benchmark for low-power ARM® Cortex™-M0 microcontrollers"

Так, приехали мои дискавери - 8S и F4
Satyr, готовься! Пока несколько дней осваиваться буду, а потоммм....