Сергей Борщ подсказал, что только что на сайте IAR появилась ссылка на 5.10 версию! Однако скачивается старая 4.41. Но наверное вскоре будет.

Что еще интересно возникло упоминание и о 4.42

В новостях на их сайте еще ничего нет, как и на фтп. Я думаю, что это кто-то из ихних веб-дизайнеров сильно поспешил или просто опечатался.
P.S. кстати на страничке ИАР ЕВ430 тоже бардак какой-то. Номер версии еще тот же числится (3.42), а в анонсе уже поддержка новых кристаллов указана, которых в текущей версии (3.42) нету.

Думаю, что завтра-послезавтра раберутся. У них достаточно обычное дело рассинхронизация.

Или сболтнул лишнее.

а с ftp IARовского который не .com ( и на который через скрытый катаог надо было заходить) вообще исчезло несколько каталогов теперь EWMIRROR там нет
это только у меня сейчас такой глюк, вроде еще недавно все открывалось.

KRS>это только у меня сейчас такой глюк, вроде еще недавно все открывалось.

не глюк - сегодня побили

И среди скрытых папок старые ссылки не просматриваются.
Такое уже бывало когда-то, потом восстановили.

Жду не дождусь IAR 5.10, надеюсь там уже STR9xxFAWxx потдержат, а то камни уже едут а компилера нету . Там конечно мелоч руками подправить но влом ...

Пришел месячный анонс от IAR, но ничего нового для ARM в нем не помянуто. Похоже на следующий месяц переползет в лучшем случае.

А чем они отличаются от обычных Fxx ?

Ну если несчстать 20% прирост производительности (это ихние слова), за счет исправления багов в мемори акселераторе, то там еще добавлено пару регистров в АЦП.

А вот интересно, код от старых процов с этими новыми 100% совместим?

Да

Ну так добавить эти регистры в .h .ddf и все. Или я чего то не понял?

Итак, появились и 4.42 и 5.10 версии.

4.42 - честно отдают, а вместо 5.10 подсовывают 4.41A

В 5.10 главная изюмина:


С 4.42 полет нормальный. 200K проект похудел на 32 байта. Код местами разбух, местами похудел. Надо будет завтра попугаемер собрать и посмотреть.

А теперь скачать можно только официальным путем?
Нет ли случайно прямой ссылки?

А чем официальный-то напрягает? 15-20 секунд на галочки?

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

Запустил попугаемер aka DHRYSTONE 1.1 - получил провал на 3% рассмотрение кода показало, что 4.42 не заинлайнил один кусочек по сравнению с 4.41 компилятором. Поднял inline_threshold до 4 вместо 2
попугаи поднялись на 17,5% (77618 в секунду на без малого 60MHz LPC2148, ARM Mode, Flash, MAM=2) по отношению к 4.41. Более чистого эксперимента не делал, поскольку 4.41 уже снес . День работы на новом - все нормально.

А где взять aka DHRYSTONE 1.1? подскажите ссылку!

Да исходники валяются с середины 80x везде . В приложении из поставки Keil-а - они на них крутость демонстрируют
P.S.
Для сравнения разных компиляторов его лучше не пользовать, ибо этот тест туп и если компилятор хорошо заточен на поиск бессмысленного кода, то он, например, выбрасывает многочисленные strcpy одного и того-же стринга в один и тот-же и получает рекордные попугаи, хотя на реальном коде все не так блестяще.
Надо будет, V2.1 запихнуть, да руки как-то не доходят

С сегодняшнего дня уже "честно отдают" и 5.10

По старому варианту папка бин не лечится. Что делать?

Значит вечером будет, опять, чем заняться

1. Проверено, обе версии принимают самодельные лицензии. Вопрос 'как' обсуждался неоднократно и
настоятельно прошу в этой ветке его больше не обсуждать.
2. Инструментарий, IDE и проекты у 5.10 другие - ставить в отдельную директорою.
3. Ассемблерный синтаксис поменялся сильно - два вагона воплей - надо разбираться
4. Хидеры для чипов переползли в соответствующие директории - давно пора было порядок навести
5. Remarks добавилось изрядно, что радует, правда у меня ввлезли уж совсем мелочные и никак не обходимые, кроме как подавлением, что огорчает


А теперь ОБЛОМЫ для Evolution

Другому линкеру не подсунуть - ЧТО ОЧЕНЬ ОБИДНО!

Без комментариев

А какому вы еще линкеру код подсовываете ? я чет всегда думал что линкер с компилятором тесно связан.


Это типа теперь не смогу посмотреть что он там на компилил ? это облом большой.

Ни фига себе. Зачем такая кака? И утилитки нет для конверсии?

Ну проект он конветирует автоматом. Ну а в ASM ручками править, впочем, как и "C" исходники. У меня стиль написания совпал с "новым"
и исправлений было минимум. А вообще довольно много разных вариантов фич похерили. Читайте "Migration Guide"





Или связан, или нет, если использует унифицированные форматы. В данном случае в 5.1 имеет место быть переход на стандартизированный ARM-ом формат. Это значит совместимость с Keil и свежими GNU. Кстати, насчет линковки - скорее всего они только отладочную информацию шифруют и как следствие линкеры линковать будут.

Странно, у меня все четыре чекбокса на вкладке лист доступны. Соответственно есть и *.lst и *.s

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

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

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

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

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

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

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

При максимальной оптимизации (галочки в проекте, без затей) по производительности получил на тестовом проекте порядка 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 .



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

В общем с 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 дешифратор.

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

На надпись Help в меню IDE нажмите, дальше там все ответы на оба вопроса черным по белому.

A keygen для 5.10 уже сделан?
Может кто то на фтп положит?

Пост #26

Это он выполняет рекомендацию по выравниванию стека по 8 байт...

Плохо что отключить нельзя вроде...

Скорее что-то не то. Выравнивание стека достигается действиями с указателем стека а не тормозными push/pop.