В архив положил gcc-4.1.2 от 20060811 binutils-2.17 и newlibc-1.14.0
Также выложил его обрезанную версию до пакета для обновления gcc для CrossWorks. Просто преписать в дерикторию ..\gcc.
Попробывал на LPC2103, работает, контроллер не жалуется. Визуально без приборов обнаружил что под кросс-ворком 4.1.2 работает бысрее (компилирует) раза в полтора, но это не важное.

Кто работает с GNU tools chain или хочет поэксперемтировать заходите берите.
http://www.klen.org/Projects/Embeded-gnu-t...last_build.html

newlibc весьма печальный вариант для cpu с малым обьемом ОЗУ (чего только стоят ctype/printf/scanf реализации). как бы dietlibc заточить под это дело - может кто патчи встречал ? Сам пока временно натырил файлов оттуда - похоже что diet в основном заточен под x86, остальные платформы в альфа стадии ;(

А это чего? Я и не слыхивал о dietlibc.Только не понятно почему Newlib печальный, ну тогда они все что расписаны на C есть печальные. Для AVR avr-libc написана 80% на асме и чесно говоря во многих местах имеет ограничения.
Если есть исходники на С, могу поробывать собрать под ARM. Там много придется перепиливать?

Три года активно занимаюсь разработкой устройств на микроконтроллерах но ни разу printf и рядом функции которые не использовал. Один раз в начале попробывал .... понял что это гранаты не нашей системы .
Так что в моей канторе разработчики printf/.... и не разу не использовали . Наверно специфика наших задач .

Кстате недавече как месяц назад взял обучательную LPC-H2103 от Olimex, решелил так сказать на армы пересесть, так вот пробывал c printf, ничего страшного, в 32к флеша и 8к рамы влез FreeRTOS, целевой код, и printf и scanf которые на UART работали. Меня все устраивало кроме скорости реакции системки, поэтому было сделано как обычно- сам принимаешь сам обрабатываешь...без чужих функций. Такчто наверно printf можно без печали использовать даже на маленьких армах, но только если скорость не нужна, например на LCD выводить или еще какое управление медленным устройством.

ну не факт.. даже для систем с EmbeddedLinux на борту (а это от 8МБ ОЗУ и выше) часто юзают ulibc заместо стандартной либо

2_Harbour

Собрал по быстрому dietlibc, в архив вошло:
1. dietlibc.a - собственно че Вам и требутся
2. libcompat.a
3. liblatin1.a
4. libm (вот это уже интересно для меня, приеду домой сравню с fp модулем newlibc по скорости)
5. start.o dyn_start.o dyn_stop.o (наверно они нах ненужны но всетаки пусть будут)

librpc libpthread libcrypt - я исключил, их без рукоприкладства сходу собрать не получилось.
заголовки у вас есть - вы качали библу.
Попробуте, отпишите че получилось. Самому интересно.

Задачи задачам - рознь, все на асме влом писать, к тому же если есть из чего выбрать сишного. newlib/uclibc проигрывают dietlibc раза в 3-4 по обьему кода.
dietlibc я тоже собирал, правда пришлось патчить librpc - задача не в том чтобы собрать, а в том чтобы иметь arm/interwork комплект библиотек, грамотно прикрученных к gcc, как это сделано с newlib.

Нет проблем. могем сделать и arm/interwork, тоесть две версии библы. Тока зачем Вам rpc?

В gcc/binutils есть понятие multilib - в зависимости от разных параметров применения одних и тех же функций (например hard-float/soft-float, arm/thumb/interwork и т.д.) gcc создает несколько версий библиотек. При компиляции проекта компилятор видя _как_ применяется f()-ия генерит обьектник из соответствующего набора. Речь шла именно об этом.

Спасибо конечно, но я знаком с этими явлениями поскольку сталкиваюсь с ними в повседневнойжизны .
Я ж говорил что собрал по бырому только под ARMv4T(ARM7TDMS-I) + ARM mode. исключительно чтоб попробывать. Чесно говоря пока не использую THUMB, у меня всегда борьба за наносекунды а в такого чтоб в флеш не влезло пока еще не разу небыло, до 40% процентов на асме прописываю. Сначала gcc генерит из C, потом я дооптимизирую выбранную трассу, напрмер код функый которые в цикле вызываются.
От libc мне интересен только libm, больше я ни чем как правило не пользуюсь

Ну так я не понял, Вам нужена dietlib собранная по полной или нет? Я так понял Вы и сами ее частично ухе собрали.

а разве выполнение thumb кода медленнее чем arm-one ? у меня все в thumb'e за исключением определенных хендлеров - проблем с наносекундами нема. А dietlibc я и так юзаю - в ручном режиме.

Я не мерял, но в документации написано что на 10-30 процентов медленне, и на столькоже компактнее. Я поверил. Иначе зачем они существуют раздельно? Дело в том что мои задачки обычно маленькие и проблнм с всовыванием не бывает бывает

Декодирование наборов инструкций занимает одно и тоже время, при грамотном буфере к флеши прирост скорости в thumb режиме может в идеале быть 160% (для 16-bit bus) см. http://www.keil.com/support/docs/2940.asp?bhcp=1

А какой "прирост", когда вместо:

такое:

А всего-то хотел

На реальных задачах получить прирост от Thumb не реально.

Ну шибко это от программиста зависит - если в лоб переносить asm код - то где-то так оно и будет. При использовании C, лично я не замечал замедления - компилятор оптимизирует функции thumb используя соответствующую стратегию - редкий код оперирующий в основном 32 битными значениями может потерять в производительности.

P.S. Я бы сделал так :

0: 4b01 ldr r1, [pc, #4] (8 <.text+0x8>) ; // 256
2: 18c9 adds r0, r0, r1

:-)
"Стратегию" это хорошо. A в Arm компилятор, значит, о "стратегических" замашках забывает и пользуется только "тактическими", дабы не выделяться :-).

Для 32bit контроллера, с исключительно 32bit регистрами и с ограничеными возможностями адресации отличных 32bit данных, "редким" является прямо противоположное.
Соэдание искуственно кода выпячивающего "преимущество" Thumb естественно возможно.
А в реальной жизни размер кода уменьшается максимум процентов на 30, что явно показывает невозможность замены команда-в команду, при этом количество команд становится больше процентов на 40
(с учетом вновь появившихся констант несколько меньше) соответственно скорость падает очень заметно.
Падение скорости при работе из медленного Flash при наличии у контроллера кэшобразных наворотов несколько компенсируется и в этом случае получается провал процентов на 10-15.

Задачи задачам рознь - понятно что баба-яга против, но для моих задач thumb режим быстрее. Есть желание спорить - ссылку на keil'овский сайт я уже давал, думаю форум у них там есть.

Хотелось-бы увидеть такую задачу (чисто из спортивного интереса) под поминаемый в ссылке LPC2000
и естественно на "C".
Я, когда ARM начал заниматься просто банальный Drystone тест для сравнения использовал и комбинации ARM/Tumb/RAM/RAM тестировал.

:-)
Не поленился, сходил по ссылке :-) Там первый пункт сначала "за здравие" (надо продажи компилятора поднимать с поддержкой новой фичи) во втром пункте уже правда:

Потом еще раз повторяют:

Причем 30-35% хорошо совпадают с моей оценочной величиной в 30% а уж падение скорости для RAM из этой величины вычисляется сразу - 30-40% ну а из Flash около 10-15%, что можно согласиться "немного".

Таким образом, "спорить" на форуме Keil мне просто не о чем.

Весь мир на лпц пока не перешел - я ж вроде ясно написал - "для моих задач", конкретизирую - железяка s-active с 16-bit шиной (http://www.colognechip.com/isdn/controllers/frame-hfc-s-active.htm), задача типично коммуникационная - управление и небольшие операции над потоком данных, благодаря thumb режиму все это дело прекрасно помещается в кеше и минимизирует обращения к флешке.
Цифры по ссылке читаем невнимательно или не знаем английский :

1) For critical code size applications, the alternative 16-bit Thumb Mode reduces code by more than 30% with minimal performance penalty.

Переводится как - Для приложений критичных к размеру кода, альтернативный 16-битный режим уменьшает _размер_ кода более чем на 30% с минимальным ущербом для производительности.

2) In reality there is minimal speed penalty in Thumb mode (compared to 35% size reduction)

Что значит: В реальной жизни скорость в Thumb режиме отличается незначительно (при 35% уменьшении размера)

Где там 30% скорости - непонятно. Лапидарнее надо быть однако

Так, тогда и пишите типа - написал как-то маленькую программку для железки с усеченной 16bit шиной, надеюсь, что получилось быстрее, поскольку на сайте Кейла написано, что так может быть.

А на Ваш вопрос:

Ответ ДА.

C английским у Вас некоторые проблемы :-(, ибо "penality" отнюдь это не нетральное слово "отличается". Рекомендую вспомнить хотя-бы футбол с его русским :-) словом пенальти.
И где в вышеотцитированном (с учетом нормального перевода, естественно) протеворечие с моим

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

Незначительно теряет, это для LPC на который по вашим-же словам "весь мир не перешел" при работе из его медленного FLASH и включении у него MAM. При работе при работе из нормальной 32bit RAM или полноскоростного FLASH провалитесь на 30-40% прямопропорционально увеличению количества команд в Thumb mode относительно ARM mode.

[qoute]
"для моих задач", конкретизирую - железяка s-active с 16-bit шиной (http://www.colognechip.com/isdn/controllers/frame-hfc-s-active.htm), задача Так, тогда и пишите типа - написал как-то маленькую программку для железки с усеченной 16bit шиной, надеюсь, что получилось быстрее, поскольку на сайте Кейла написано, что так может быть.
[/quote]

Ну так и Вы пишите - "никогда с другими процами кроме LPC не работал, но уже знаю что они медленнее в thumb'е на 30-40%, потому что так может быть".



Ну, беру свои слова обратно - насчет keil'овского форума - рановато Вам еще туда - для начала нужно здесь еще будет отгрести пару лет, для боевой закалки, так сказать, а то нервы ну прям ни к черту



Что-то так и не заметил лапидарного перевода словосочетания "minimal speed penalty" в контексте данного предложения.



Жалкая попытка перейти на личности, вещь для инженера - недостойная, ну а конкретно для вАС и совершенно невозможная.



Еще раз для танкистов - ARM и ARM-THUMB это просто архитектура, и коей кроме
лпц есть еще немеряно реализаций, включая совершенно на лпц непохожие. Грубо это значит - что русскому здорово - другому смерть. Но танкисты смотрят через дуло - обычно это тяжелое наследие x86 программизьма - один проц, одна система, одно и то же железо - почти как в анекдоте про тяжелое детство с чугунными игрушками

Ну что можно сказать: весьма печально наблюдать в рядах инженеров такой вот подход, т.е. вместо того чтобы оценить особенности эффективного применения того или иного подхода в программировании, товарышi скатываются на навязывании, я бы сказал, своего, весьма ограниченного, взгляда на существующее положение вещей. Как по мне, так кардинально нужно менять или подход или товарищей

Вот и новый анек почти в тему :

- А ви чули як лапiдарные товарiщi називають АРМ ?
- Нi куме. Як же ?
- Эль-Пе-Це !
- Повбивав би гадiв ...

Что касается LPC, то для тех, кому кажется, что они на войне и все остальные находятся "в танке" - с его архитектурой разница Thumb/ARM много МЕНЕЕ заметна, чем, например, у Atmel и STR c FLASH работаюцим на частоте ядра.

C быстродействием ARM/Thumb думаю тоже уже читателям все ясно.

P.S.

Боле, чем жалкий и более, чем недостойный и немотивированный переход на личности вЫ уже ранее предпринимали. Чем собственно и был вызвано мое предположение о личностных "проблемах".
Я это помню, хотя модератор это и вытер.
Представление о вАШЕМ уровне самомнения и способности понимать (вне зависимости от языка ), каждый может сделать сам из переписки и комментировать я это не буду.

Мдяя...
Пока я выходные охотился на болотах и водку пил с друзьями, тут прям, смотрю, неустанно без выходных люди трудятся!! Стахановцы! хватит балоны катить друг на друга. Вы уже план перевыполнили на 300%.

Тема про gcc, про его любимого есть что по существу сказать? А?

Извинине :-( за спонтанное отклонение от темы :-(. Хотя и с Вашей :-) подачи...

P.S.

Если на "Псковких", то рановато уехали - я завтра в Себеже -> Пскове буду....

Ну нельзя сказать что и я кристально трезв в воскресенье "С существом" и "по существу" вроде тоже в порядке