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


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

Для 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МГц и полумегабайтами озу и пзу не до фортрана и тем более не до с++

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

Сообщение отредактировал en1gma - Jun 27 2011, 20:26

Вы таки думаете что я первый раз замужем? а вот нет! развелся! завязал я со службой государевой. и то что Вы написали сверху для меня не хужлитература а тоска и безнадега в которой 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