А у меня выдается и листинг и чистый asm файл
но вот синтаксис они совсем поменяли

В догонку:
Так теперь нет XLINK (универсального для всех чипов) у ARM свой линкер ILINKARM лежит в ARM/bin
и вместо xcl файлов теперь icf

Но самая большая Ж....
теперь с вычислениями - в выражении нельзя использовать 2 глобальных символа - т.е например размер сегмента (теперь секция) получить нельзя. надо грузить начало и конец и вычитать в период выполнения.
Такую конструкцию соотвю тоже не запихать
ldr PC,[PC,#0xFFFFF030 - (.+8)] //VICVectAddr
ругается - слишком сложно.

Подтверждаю - работает. Обманули, значит

Поменяли, в принципе что в лоб, что по лбу. Но! Что-то там еще поломали Отказывается ассемблировать ранее понимаемый код, причем диагностическое сообщение хоть стой, хоть падай.
Поломал голову, но нашел методом тыка. Для желающих потренироваться в расшифровке диагностики - файл в приложении

Ага, и mapfile просто никакой и что-то я линковочных наворотов имевшихся у xlink пока не найду.
Похоже они его наскоро из GNU слепили.

[..........]
Скомпилировал проекты - все нормально, листинги есть
При отключенной оптимизации - размер кода моего проекта 90200 байт против 95824 (ver4.41)

Сообщение отредактировал zltigo - Jul 13 2007, 21:20

При максимальной оптимизации (галочки в проекте, без затей) по производительности получил на тестовом проекте порядка 600 байт уменьшения на полторы сотни килобайт бинарника. Заливать не пробовал - не дошли руки, но листинги пытался сравнивать с 4.41/42 - отличия радикальные, глобальная оптимизация похоже или круто работает или круто лажается . Надо будет завтра попугаемер пообъективнее собрать и с осциллографом по интересным местам пройтись....

М-м-да! Я уж было подумал, что производители компиляторов достигли или уж по крайней мере близко подошли к некоторому гипотетическому пределу совершенства.
ИАРовцы удивили в очередной раз.

На самом деле если не удивили, то порадовали.
1. Компилятор (в прямом смысле этого слова) явно стал
генерить шустрее код, похоже, за счет глобальной оптимизации. До более менее объективных оценок производительности еще не добрался - осваиваю инструмент, но разница заметна почти невооруженным взглядом.
2. Библиотеки ПЕРЕПИСАЛИ! По крайней мере невыносимо тупой IARовский memcpy() ускорился на копировании невыровненного массива с некрасивой длинной в 63 байта почти в четыре раза и стал вровень с писанным на ASM.

С остальным иструментарием - все поменяли и он сыроват даже при поверхностном знакомстве
Завязались на binutils и выкинули из линкера в отдельную утилиту ichecksum, но забыли приложить юниксовый шелл....
Про ASM уже писал - рихтовать надо и отупел он несколько
Свой листинг выбрасыает прямо в stdio - прикольно смотрится компиляция в IDE.
IDE я пользовался мало, но пока пользовался - разок уронил и все замеченные мной ранее интерфейсные глючки на месте остались .

Линкер многократно доводил до воппля 'internal error'.
В линкере документированы вкусности, но чего-то не удалось даже красиво прилинковать секцию с конца RAM - либо витеевато ругался, либо 'в данной версии не поддерживается'. Обойти, конечно, обошел. При линковке ROM, пока не вынес последнюю секцию из общего списка в отдельный - линковал уже за ней кусок даных для инициализации. И вообще конструция типа

не только в вышеупомянутом случае работает неправильно, ибо __section_begin() возвращает для всех болоков один адрес, а в ASM все
нормально.

Документация на новое плохая , например, если судить по ней, то ichecksum нужно сразу в мусорник засунуть, я уж было собирался свою писать, но случайно заметил в логе, как она используется изнутри линкера. Однако, чуть было не выбросил вторй раз, если-бы случайно не догадался попробовать для того, что-бы вычесть 1 при указании range прибавить -1 .



Но в принципе, уже почти все нюансы (шел от сложных к простым) портирования победил, остались мелочи которые не получиться не могут.

Сообщение отредактировал zltigo - Jul 14 2007, 15:01

В общем с EWARM 5.10 все в порядке. В пределах необходимых для нескольких текущих проектов за выходные дни освоил. Несколько тонких мест в "С" исходниках пришлось вынести под __IAR_SYSTEMS_ICC__ >= 7 (кстати 7 а не 6, как в документации на 5.1 описано).
Startup-ы переписаны заново, ASM файлы подогнаны под совместимый вариант, конфигурации линкера естественно совсем другие. Подсчет контрольных сумм и конвертировку в другие форматы теперь делает не линкер, посему добавились инструментов (пользователям IAR IDE теперь придется на Postbuild cmd файл вешать ).
Подсовывать объектики другому линкеру не пробовал - завтра займусь, но GCC и ADS библиотеки линкуются, что очень хорошее подспорье. С ImageCraftV7 что-то не заладилось.
Большие проекты (при максимальной оптимизации), как уже писал, чуть чуть уменьшаются по объему, но тестовый проектик в 20K разбух до 24K.
Выберу минутку bootloader попробую портировать с минимизацией размера.
Dhrystones 2.1 выдал 83544 попугаев против 73088 при компиляции 4.42 это больше 14%.

Я вот в мигрейшен гиде прочитал что теперь ни ассмблер ни компилер не делают несколько модулей в одном файле т.е. файл всегда линкуется только целиком.
Получается что лишнии функции выкидываться не будут или надо делать кучу файлов по одной.

По идее должны выкидываться если к ним нет обращения.
Проверить пробовали?

Естественно при использовании стандартных форматов не выбрасывает. Фича была неплохая, но не общепринятая.
Отсутствие ее в общем-то привычно.

P.S.
Библиотеки, конечно разбухли - bootloader не влез, ибо разбух почти на килобайт при оптимизации по размеру. Весь код примерно на том-же уровне остался (обычно чуть поменьше) но библиотечные функции разбухли. Таже резко пошустревшая memcpy() стала около 190 байтов, вместо нескольких десятков. printf() раза в полтора увеличился. Пришлось писать свои - результат почти 2K экономии.
Кстати, у линкера нет доставшего xlink-овского глюка
http://electronix.ru/forum/index.php?showt...10&hl=xlink
заполняет все под завязку.
ichecksum работает хреново в непонятных случаях ломается на границах ASM и 'С' секций даже если они стык в стык линкуются. Вопит, что содержит неинициализированные области а при попытке ему-же приказать заполнить находит зону стартовый адрес которой на единицу меньше конечного . Обойти не удалось .

Я только одного не понял! Зачем они поддержку UBPROF вообще удалили, ну добавили бы EABI как опцию.

Посомтрел я несколько листингов от 5.10 для THUMB, код почти один в один, за исключением стека 5.10 больше ригистров сохраняет, зачем непонятно! например R0 зачем то сохраняет в стеке в начале функции. Внутри перед вложенным вызовом зачем то сохраняет LR (который уже сохранен в начале) в итоге код от 5.10 больше и стека больше жрет.

И пользуюсь и смотрел только ARM. Коды отличаются очень сильно (смотрел, естественно функции о много десятков строк).
Единственно, где THUMB используется это загрузчик, но там код не смотрел - только размеры функций по листингу. Одни чуть меньше другие чуть больше. Единственная функция которая выперла на 5.10 по размеру на пяток процентов побольше это AES дешифратор.

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