все ссылки в этой ветке форума.


вот и я тоже считаю что пора прорядок в сарайчике навести.

Для AVR, хост windows-x86 есть?

windows-x86 скольтки разрядной ?

я на AVR подзабил, у меня нет и не будет на нем проектов. крайний раз когда пробовал собирать были глюки в генераторе отладочной информации в формате DWARF - компиллер падал при попытке ее формирования для компиляймого файла. тоесть можно было собирать проектв но без отладочной информации, я не стал выкладывать такое.
для порта avr было вообще все нафиг разломано и брошен.

я попробую посмотреть есть ли новости в транке по этому поводу. если ктото пытался починить то попробую собрать.

Windows, 32 бита. Пигмей в квадрате.

Отладка не интересует, dwarf вормировать не буду.
Если от winavr издания ноября 2010 года не будет отличаться, не заморачивайтесь.

а как узнать без сборки? я не шаман

Инет заработал, спасибо за код. Будем копать!

по-тихоньку, присоединяюсь к тестированию сборок под 5980ВЕ, не даром, АФАИК, это чудо было сделано по заказу нашего предприятия, да и я с ним мучаюсь уже 2,5 года..
кстати, очень интересны результаты переговоров с НИИСИ, так как свой компилятор они в комплект процам не предоставляют, а предпочитают его всё же продавать. кроме того, будет интересен дальнейших ход событий с дебагером..

P.S. код, собираемый gcc 3.хх с mips-таджетом (-march=r3000 -mhard-float) в своё время на железе не запускался.. требовались какие-то "комдив32"-совместимые патчи, поэтому использовали и используем до сих пор их компилятор

это потрясающе....
сейчас я общаюсь с тремя анонимно разработчиками(или группами - мне не известно) которые используют комдив32. что вас объеденяет? комдив? не только! вы все какие то мутные. если так будет продолжатся то я плюну и брошу это неблагодарное занятие. Выложил две сборки - бери тестируй, что то расковыряли - сообщили, я подкрутил - опять проверили и т.д. НИЧЕГО - одни какие то рассуждения о непонятно о чем. Ни один из Вас так и не сообщил мне - пробовали ли компилять моей сборкой или нет и что получилось/не получилось.

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

по поводу "требовались какие-то "комдив32"-совместимые патчи,..."
ребята... Вы сначала хотя бы определите ревизию кристалла которые Вы мучаете, а потом про патчи говорите.

объясню достаточно просто, цена на это чудо-юдо на текущий момент составляет 90 тысяч рублей за штучку - поэтому оно совсем не популярно.. только в определенном секторе.. и только по принуждению сверху..
второе, "настоящие программисты" (ну те, кто так значится по штатному расписанию и кто отвечает головой за код) это дядечки далеко за 40 и они особо баловаться не будут (наши-то записать бинарь во флешку не всегда могут да, например, пишут в кейл 2.х, так как кейл 3.х "не так выглядит")
третье, твоя сборка (или как это назвать, чтобы было верно по-научному) преспокойно собирает ассемблеровский код (было бы удивительно если не собирала) и достаточно простой С-код, осуществляющие чуть больше чем запись/чтение в память и дрыганье ножками
четвёртое, серии кристаллов ведут себя по-разному. "а в этой партии вот то, то и то не реализовано или реализовано криво"(с). кроме того списка "время выпуска / партия"-"ревизия"-"список ошибок" как-то не попадалось
пятое, будем очень благодарны если будет собираться под вин32 хост с таджетом "сферический" мипс, в котором есть библиотеки как для софтового (чтобы дружило с тем же пик32) так и для железного флоата, так как, в моём случае, на мипсе2 на ~20МГц и полумегабайтами озу и пзу не до фортрана и тем более не до с++

зы простите нас не_разумных

Вы таки думаете что я первый раз замужем? а вот нет! развелся! завязал я со службой государевой. и то что Вы написали сверху для меня не хужлитература а тоска и безнадега в которой 15 лет провел. Всецело понимаю и сочувствую.


пол мегабайта???? да это вселенная. я больше 64к пока не встречал. однако с успехом использую и фортран и С++. уверяю, то что "С++ это не то что походит к микроконтроллерам" - глубочайшее заблуждение порожденное непонятно чем. я специально пытался это понять но размного ответа не нашел. Вопрос в том что все нужно умело применять.

сферический мипс это здорово!
в данной ветке выкладывается одна из сборок специально для юзателей pic32 - такчто уже все "было". в ней софтовая плавучка а для комдива с железной.


no comments


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

все свежаки которые я собираю - собираются из транка, если всплывают косяки я их по возможности правлю чтоб собралось, потом тестирую в силу возможности и тоже правлю если опятже косяки в кодогенерации. То есть по сути - сборки экспериментальные и могут работать с ошибками. Но сегодня сборка экспеерментальная в квадрате. я потратил время на то чтоб разобратся с LTO + Gold.
LTO - оптимизация времени линкования. те кто еще не интересовался что это такое то можно почитать тут (коротко на русском) http://kemiisto.blogspot.com/2010/08/gcc-4...timization.html и тут http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gc...ptimize-Options

GOLD (gnu ld.gold) - это новый эксперементальный линкер который возможно заменит классический LD (gnu ld.bfd). штатно входит в binutils. Google и многие проекты - LLVM, GNU итд, его используют тестируют и девелопят как основной. основным локомотивом его разработкии внедрения является google. в маках кажется тоже он штатно используется.

не для кого не секрет что в больших проектах (не таких как у нас - эмбедеров) основное время сборки занимает линковка. поскольку Gold был задуман как линкер больших проектов, его рамках сразу делали LTO. до сегодняшнего дня у меня LTO не работало - я тестировал на сложном проекте, использовал обчный LD, проект состоял и з можества собранных либ и тд. пришло время.....

итак. сегодняшняя сборка по умолчанию использует в качестве линкера Gold. все библиотеки GCC и newlib собраны c опцией -flto. проект собирался тоже с -flto. речь будет идти про arm таргет.
код генерится рабочий. но есть нюансы...

1. при линковке нада передавать также и флаги оптимизации ! если не передать то линковка падает. ( ув. тов. АНТОХА это обнаружил раньше меня ). я думаю это ошибка в компиллере - эти флаги и так можно хранить в секциях объектника да еще они могут быть разными у разных объектиков
2. LTO - это реально ЖЕСТЬ!!!!!. после первой сборки я обнаружил что проект уменьшился в два раза.... начал ковырять. оказалось оптимайзер нафег выкинул таблицу векторов прерываний! выкинул функции - обработчики прерываний и тд много чего.
я сначала ошалел - а потом попробывал представить сябя на его месте. и действительно - таблица векторов это тупо массив байтов. он же не знает что это такое. к этому массиву из кода не происходит никаких обращений - значить это мертвое - отрезаем...
обработчики исключений - таже истоия - они "апаратно" вызываются.. и так далее и тому подобное.
для того чтоб вернут взад вектора я сделал в crt коде одно фиктивное обращение к таблице на чтение содержимого - и Gold впечатленный этим оставил структуру в котой у менф оформлена таблица векторов в покое - она появилась в бинарнике с нужного адреса. далее некоторым функция пришлось воткнуть атрибут externally_visible чтоб он их не выкидывал.
3. есть шаманство с вызовом main из crt кода, с другими функциями я не заметил такого. както очень хитро это происходит. надо разбираться.
4. если функция вызывается из асемблерной вставки - то ни комиллер ни голд это отследить не может и выкидывает ее как ненужную, далее получаем неразрешенную ссыку на конечном этапе линкования. в этом случае надо помечать такую функцию атрибутом externally_visible примером такой функции может служить void xPortPendSVHandler( void ) из FreeRTOS
5. линкер выдает мессагу которую я пока не понял юмора :

6. РЕЗУЛЬТАТЫ
сборка от 19 числа стандартный линкер ld.bfd
без LTO



c LTO

бинарь не работает - изгажен crt. видимо както можно заставить но у меня не получилось, явно видно что выкинул и то что нужно! как он смог слинковать после этого!?? нада дифы листингов курить...

сегодняшняя сборка с Gold без LTO


сегодняшняя сборка с Gold c LTO

РАБОТАЕТ!!!!! НО..... что он делает с кодом ! я в листингах ваще концы найти не могу. отладчик уходит в астрал и в состоянии только остановить и пустить код далее - ничего более, даже адреса глобальных переменных определить не может. глядя асм видно что функций уже видимо нет! все нахрен так перемешано что там где ранее были переходы из дной функции в другу - их там просто нет - линейный код! полный ахтунг.
но подчеркиваю - оно както работает. что честно говоря изумляет. у меня сложный проект на С++ с испоьзование вычисленй на плавучке и FreeRTOS - гденибудь да вылез бы косяк, однакож честно все считается и работает.
6, видно что зачемто LTO увеличивает расход ОЗУ, что это косяг или так вынуждено - пока не исследовал. нада файлы мапы памяти смотреть и разбиратся. пожже.
7. есть недостаток но для нас эмбеддеров не существенный - преред линковкой все объектиники загоняются в память и ликер по ним ходит и отимизирует. соответственно слинковать проект объем объектников которо больше чем ОЗУ хост машины - нельзя, правдв идет работа у разработчиков чтоб это кусками можно былобы делать.
8. довольно долго GDB учили понимать отоптимайщеный код - научили. затем очень доло его учили понимать код сгенеренный компиллером C++ (шаблончики, виртуальные методы и конструкторы в сошках и прочая...) типа щас более менее но не всегда цепляестя за код. С LTO видимо будет полная попа - на выходе настолько не то "что вы имели ввиду" что похоже отладчикам ничего не светит даже в отдаленной перспективе. хотя кто знает.... про дебаг неоптимизированного кода я не говорю - считаю актом практически не несущим новой информации в эмбедед.
9. в итоге видим что LTO вещ чумовая и сравнительно новая, неустоявшаяся. но на мой взгляд это реальный идейный прорыв в методах оптимизации. на данный момент все в стадии отработки и вопросов пока больше чем ответов.


все это можно поробывать в действии - сборка для хоста linux 64bit
http://klen.org/Files/DevTools/linux-x86_6...ld-lto.tar.lzma

Если этот линкер использует скрипты того же формата, что и старый - то достаточно в скрипте обрамить нужные секции в KEEP() и ничего не будет выкидываться без всяких шаманств с фиктивными обращениями. Такое и раньше происходило по --gc-sections.

в тероии.
а на практике

выкинул структуру с векторами которая укладыватся в секцию flash_vec_table
без lto не выкидывает. еще предстоит понять как скрипт линкера влияет на lto, наверняка что вылезет новое. линкер то другой!

Спасибо

свежак для ARM хост linux x86_64
http://klen.org/Files/DevTools/linux-x86_6...110807.tar.lzma
размер 81Mb

openocd стал (насколько мне удалось натестить) хорошо работать с stm32f2xx

хехе... настают благопритные времена занятся dsp!!
проспал новость о том что две недели назад в gcc добавили порт для TI C6x ядер! это по мойму польшой прогресс в целом.
дотошным исследователям рекомендую заглянуть в исходники порта http://gcc.gnu.org/viewcvs/trunk/gcc/config/c6x/

в чем значимость этого события (на мой взгляд конечно )?
TI не щадя своих сил и разорваных от натуги штанов пиарит свои свежие OMAP'ы - а там (в свежих омапах) имеется 2 ядра Cortex-A9 1ГГц 1 ядро С64+ 800МГц и GPU powerWR SGX545 (на нем тоже можно лихо гонять в хвост и гиву многие алгоритмы с плавучной - например работа с матрицами больших размеров)
Вот они умные - поняли что средсва разработки на основе gcc это круто и теперь можно используя один компиллер генерить код для всех вычислительных компонентов системы на кристале!

у меня есть плата http://pandaboard.org
там какраз стоит этот зверь TI OMAP4430

я впечатлен производительностью.... теперь еще и можно полностью gnu-шными тулсами его разраьатывать.

сдается мне что следущий раз если получится выложу сборку и для c6x .... соберется... пора учить даташиты по С64+.

уря уря уря товарищи!!! паровоз прогресса нельзя остановить... только пустить под откос!

счастливо потирая руки ну теперь я знаю, кого здесь можно будет мучать вопросами по pandaboard - коробку с оной распаковал 3 дня назад

Извинте на назойливость.... А можно windows-x86_32?

постараюсь на выходных.

батарея свежаков
для хоста x86_64 linux
arm:
http://klen.org/Files/DevTools/linux-x86_6...0110814.tar.bz2

avr (решил встряхонуть старье - у меня есть не запаянные меги 48 168) :
http://klen.org/Files/DevTools/linux-x86_6...0110814.tar.bz2

i686:
http://klen.org/Files/DevTools/linux-x86_6...0110814.tar.bz2

TI C6X - супер свежак, порт добавлен как я выше писал несколько недель назад, естественно не пробывал - нада тестировать, собраны только бинутилс и gcc
http://klen.org/Files/DevTools/linux-x86_6...0110814.tar.bz2

x86_64_linux
http://klen.org/Files/DevTools/linux-x86_6...0110814.tar.bz2


для 32 битного масдая как обещал для армов (не тестил, если чтото забыл положить доложу, пишите)
http://klen.org/Files/DevTools/arm-kgp-eab...0110814.tar.bz2

Заранее предупреждаю, старого каталога с бинарниками не существовало, всё разархивировано начисто (WinRAR, из-за такого экзотического формата архива). Старые .o тоже были стёрты. Это проект под at91sam7

Без -flto не сыпется, результат на работоспособность не проверял.

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

Можете заархивировать в .zip или, как обычно, .7z ?
Раньше работало...

Спасибо, и за старьё тоже :-)

А такое есть arm-kgp-linux-gnu? Именно нативный, а не кросс. Столкнулся с NAS от dlink. Многое из того что хотел бы доставить в пакетах нет. Нужно ставить из исходников, а родной gcc мало того что старый (4.1) так еще и обрезанный по самое немогу.

по идее это еще проще чем для микроконтроллеров. в данном случае требуестя собрать только бинутилс и компиллер - libc -реализует сама система, по сути это ее библиотека. если развивать идею дальше - то бинутилс и компиллер ничем не должен отличатся - иx дело генерить код из инструкций проца - а где это запускается это уже выруливать должны библиотеки. за одним исключением - скрипт линкера естественно различается. можно попробывать собрать когда будет своюботдное время.

2_ReAl
ну и как? работает? что с выходным результатом - он стал лучше чем прежде или нет?

Genadi Zawidowski
ну какая связь между способом архивации и работой разорхивированного приложения?
у меня другая идея - пересобрать libppl libcloog - ими пользуется lto, может поможет.

Ещё не успел глянуть -- поставил в очередь на закачку и сразу убежал на совещание :-(
Или вечером дома, или завтра уже.

А помните, была мысль собрать всё статически, без либ? А то у меня убунта после установки прошлой сборки и применения ldconfig перестала нормально обновляться. Пока не снёс эти либы - обновление завершалось с ошибкой. Типа, в этих либах нет информации о версии.

Я где-то в этой теме уже писал, у меня другие глюки были (какие-то программы перестали находить нужное себе).
Я обошёлся так:
В makefile, выковырянном из примеров scmRTOS :-)

Ну и

Спасибо, попробую так

А lib к ним?
Все эти libppl_c.so.4 и компания. А то у меня от прошлого разворачивания (еще 20100525 или что-тов этом духе) там аж libppl_c.so.2 и с прочим аналогично.

upd:
Ага, оно в x86_84-kgp-linux, только этот архив у меня что-то при распаковке ругается в духе "попросили распаковать, а такой файл уже есть" (распаковываю в ~/downloads, там такого точно ен было ещё). Потом разберусь, опять убегаю...

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

свежак ARM для хоcта linux x86_64

http://www.klen.org/Files/DevTools/linux-x...abi-20110924.7z

обновился GDB до версии 7.3.1
openocd собран с подержкой:
ft2232 устройств
jlink
rlink
usb_blaster
amtjtagaccel
zy1000-master
presto
usbprog
vsllink
ulink
arm-jtag-ew
buspirate

в /doc лежит сгенеоенная pdf дока по openocd

binutilsтеперь будет собиратся c обоими линкерами - ld и gold
рекомендую разработчикам больших проектов в которых линковка занимает большое время попробывать gold. я лично першел на него полностью - пока нигде проблем не возникло.

после длительного тестироваия оптимизации LTO принял решение использовать это шаманство с бубном в рабочих проектах при необходимости.
таким образом все либы в сборках будут компилятся с поддержкой LTO, для тех кто не скажет линкеру оптимизировать это останется прозрачным.
вот типовой выхлоп этой оптимизации на моем рабоче-тестовом проетке
11 задач FreeRTOS + одна для програмных таймеров + одна idle
большинство объектов динамически реазмещаются в куче
работет переферия I2C для чтения акселерометра
осуществяется вывод перегрузок на ЖКИ
выполняетя плавучка - преобразование Гильбера, пересчет системы координат акселерометра,
организован обмен по USB
реализовано на С++
FreeRTOS обернта в классы
имеются виртуальныей функции
тоетсь проекти не такой уж и примитивный

результат сборки без LTO
memutz .././../out/image.elf 512K 64K
section info:
sec name size increase[%]
.text 22416 0 (0.000000%)
.data 512 0 (0.000000%)
.bss 33270 0 (0.000000%)
utilization:
ram : 51.5472% 0 (0.000000%)
flash: 4.37317% 0 (0.000000%)

результат сборки c LTO
memutz .././../out/image.elf 512K 64K
section info:
sec name size increase[%]
.text 19656 -2760 (-12.312633%)
.data 539 27 (5.273438%)
.bss 35234 1964 (5.903220%)
utilization:
ram : 54.5853% 1991 (5.893672%)
flash: 3.85189% -2733 (-11.919922%)


итого видно что в конкретном случае по флешу ужатие 11%
по озу 5% в гору
что на мой взгляд выдающийся результат для отдельного метода оптимизации.
разумеется после зашивки девайс работает аналогичо. скоростные характеристики кода не исследовал.
напомню что в линкер нада пропихивать тотже ключ оптимизации как и при компиляции. в данном случае -Os -flto

на подходе cortex M4F.. вот покуражимсо! ждем и потираем руки..

Как обычно, приму с юлагодарностью ARM для хоста WIM32

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

по ходу обновил сборку mingw32
http://klen.org//Files/DevTools/mingw32/i6...w32_20110925.7z

сборка ARM для win32
http://klen.org//Files/DevTools/mingw32/ar...w32_20110925.7z

не тестировал

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

Ёжики не лезут на пингвинов.

Протестирую.

ps: протестировал: LTO с ARM7 отвалилось (Segmentation fault в lto1.exe).
Жду следующей версии. В позапрошлом варианте работало - пока сижу на нём. Не колет.

прискорбно, какнибудь помотрю и попробую разобратся.
LTO в Ваших задачах безусловно необходим? если да то расскажите поподробней почему.

без LTO новая сборка дголжна быть лучше, как минимум GDB обновили - стал более адекватно сложные вещи выполнять.

Нет, LTO критически необходимым не является - пока ещё до предела в ПЗУ не дошёл. Просто отваливание этого куска выглядит как индикатор того, что что-то не так в оптимизаторе.

Хотя... Была идея запихнуть проект в 32-килобайтный процессор (с LTO - 25 кБ, без - 33 кБ)... пока можно пользоваться старой версией.
GDB не пользуюсь...

Господа, имеет место такая вещь:
Сборка с ключом оптимизации -О2 создает вечный цикл в 2 команды в виде джампа на самого себя. Без -О2 такого не наблюдается и все работает. Было сделано предположение, что один из внутренних ключей -О2 дает такой эффект.
Из интернетовских источников был развернут -О2 на составляющие флаги, НО! -> размер бинарника не сократился в той же мере, как при -О2, и к тому же продолжает нагло работать.
Вопрос в том - какие ключи отвечают за оптимизацию бинарника по размеру? кажется собака рылась там.

Такой жалобы на отсутствующий у жалующегося в коде ключевых слов volatile в нужных местах я еще не видал

Точно! И почему до меня сразу не дошло?! Место в луже мое -O2 заработал!

а ёжиков, которые все еще лезут на AVR с Win32, не пожалеете?

увежаемый klen почему компилер может не находить библиотеку?
Распаковал архив arm-kgp-eabi-20110924.7z в папку /opt/arm-kgp-eabi-20110924, сделал симлинк в /opt/arm-kgp-eabi прописал путь к bin
При попытке откомпилировать gcc валится с таким сообщением об ошибке:
/opt/arm-kgp-eabi-20110924/bin/../libexec/gcc/arm-kgp-eabi/4.7.0/cc1: error while loading shared libraries: libcloog.so.0: cannot open shared object file: No such file or directory

мой косяг видимо. до дома доберусь проверю, корее всего п окакойто причине либа libcloog.so.0 не сложилась в архив или битая. поправим.

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

Не забывает кешировать либы! товарищи! ldconfig приходит на помощ...

Солнце еще не погасло, но я кажется начинаю разбираться.

Вопрос по коду. Он вылетает в ошибку если пытаться .bss сунуть в память сразу после .data (пытаюсь расположить их в оперативу)



Ошибки выглядят вот так:

Остальные аналогичные.
Почему не дает-то? по всякому уже пробовал...

2_Ash_snz
уу.... бойци невидимого(или недвижиммого ??) фронта прорезались...
дайте карту раскладки памяти на кристалле(плате), напишем Вам тестовый скрипт линкера, а то тот который Вы предлагаете чудной.


2_All
собрал спецсборку для CortexM4, все либы что используют плавучку ( втроенные операции над типом float и libm )- особраны с использованием FPU. пожже выложу. люди хелп...дайте кому не жалко платку с stm32f4xx напрокат потестить компиллер...

свежак для ARM. хост - linux64

http://klen.org/Files/DevTools/linux-x86_6..._64-20111108.7z
75.2 Mb

в мультилиб добавил отдельный вариант для микросхем Cortex-M4 и Cortex-M4F

соответственно при компиляции с ключеми -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 будет компилятся код с подержкой cоспроца и также будут линковатся с версиями библиотек которые собраны с этими же ключами (libc libm libgfortan ... ). в выходном коде Вы с радостью обнаружите инструкции сопроца.

если подсунуть только -mcpu=cortex-m4 то процес аналогичный за исключением того что либы без поддержки сопроца, но за счет того что в едре четверки реализован simd набор можно тоже получит профицит по сравнению с кодом скомпленным с -mcpu=cortex-m3 (который в обязательном порядке должен работать на Cortex-M4 )

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

Бойцы невидимого фронта сильно зависят от задач, которые ставят выше.
ОК, Раскладку нарисую. А почему чудной? вроде довольно последовательно...