Люди! Кто прикидывал во сколько раз больше получается код если писать прогу на сях, а не ассемблере? Мне хотя бы грубо.

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

Хехе, начинается... Под аРМ даже прикидывать не хочется. Если просто смотреть на код IAR и realview, то мне кажется, что я смог бы написать лишь на 5-10 % короче, причем скорее 5, чем 10.

Опять же от проекта зависит. Сколько кода непосредсвенно Вашего (на асм-е), сколько чужого (библиотеки), сколько констант (тех-же строковых порой пол проекта)?

Ну а дальше всё уже упирается в способности компилятора, которые порой проявляют "чудеса изобретательности. Понятно что эти чудеса можно и самому писать, но трудоёмкость отличается в разы.

В общем случае я ответил бы так:
В идеале - ни на сколько
Однако все зависит от многих факторов.
Я видел программистов, которые на ассемблере пишут код хуже, чем тот же алгоритм написать на си - но это частные случаи.
В основном же все зависит от того, на сколько опытный программист ... на сколько глубоко он понимает принципы работы компилятора си, каким хотя бы примерно (структурно) будет код на ассемблере после компиляции си проекта.
Однако, многое еще зависит и от компилятора. Применительно к AVR мне лично очень сильно не понравился winavr - код громоздкий и неуклюжий... Сейчас пока остановился на codevision ввиду того, что с ассемблерными вставками трудоемкость создания кода наряду с его конечной производительностью очень сильно впечатляет. IAR честно скажу не пробовал. Все компиляторы обладают своим уровнем оптимизации... но ни один из них конечно не заменит чистого ассемблера - но это еще раз повторяю, применительно к AVR. А вот если например взять старое доброе ядро 8051, то тут дело обстоит совсем иначе... Здесь например очень порадовал компилятор Keil uVision - оптимизация и лаконичность кода просто поражает, и не думаю, что под данное ядро стоит писать на языке ассемблера вовсе (при условии, коненчо, что не будешь "гнать пургу" на си).
При всем при этом хочу заметить, что на настоящий момент применение ассемблера для создания целого проекта практически нецелесообразно. (бывают конечно частные случаи, но довольно редко)
Трудоемкость - выше, читабельность исходника при негустых коментариях и непонятных названиях переменных практически нулевая А выигрыш - ну максимум 10 % в размере/скорости работы ПО при самом хорошем компиляторе.

хотел бы я посмотреть на ассемблерный проект в 100К строчек.
про переносимость можно просто забыть.

Ассемблерный проет в 100к строк это очень круто. ;О) Если имеются в виду строки кода.
20К строк, как правило, это управление весьма непростым прибором с навороченой логикой работы и неимоверным кол-вом математики.
А что касаемо переносимости, да всё прекрасно переносится.

Нискажите. Например в арифметике может отличаться в разы. Деление, например, в общем. И деление на константу, в частности. Наиболее ярко разница может проявиться на малоразрядных контроллерах. А если это критическая секция, то... ;О)

1) Никто и не предлагает писать 100 к на ассемблере
2) Переносимость си с ядра на ядро тоже не является легким делом, не будем лукавить. У всех ядер свои архитектурные особенности, свои компиляторы со своими багами, и если все это учитывать - про переносимость в большинстве случаев тоже можно забыть

mse не слушайте , он все время жжот

"Тяжело только первую тысячу лет" © Шекли
В-общем-то, один из наших проектов - 100K+ сишных строк мигрировал так: x186->AVR->MSP430->MBM90->ARM7.
Сложным был только первый порт (до двух недель ковырялись), а все остальные - за день-два. То есть - один раз себя дисциплинируешь, а дальше оно само катится.
Что до subj - имхо, ARM имеет очень "враждебный" по отношению к человеку ассемблер. Писать на нем нудно и долго. И не всегда эффективно. У меня был пример - процедура вычисления кода Хемминга для сектора NAND - сначала я этот кусочек написал на ассемблере, потом - на C. И надо признать, что GCC компилятор у меня в тот раз выиграл. И не потому, что я плохо знал архитектуру ARM Просто компилятор - он же "железный" - рассматривает все возможные оптимизации и выбирает лучший вариант. А программисту обычно лень подумать несколько раз над одной и той же проблемой. В итоге, в моем случае C-компилятор хитро поскрещивал арифметические операции со сдвигами и уловными флагами и получил код в полтора раза быстрее и короче чем мой "ручной". Мне оставалось только "убить сибя ап стену"

Как писали выше все ОЧЕНЬ сильно зависит от мастерства программиста.
Например, неделю назад писал функцию автокалибровки (C8051F06x, есть 9 каналов по 8 под диапазонов на каждом, калибровка по 12^2 отсчетам) из оболочки передается структура с кол-вом калибруемых поддиапазонов, индексами поддиапазонов и количеством напряжений на поддиапазон, например -5, -2, +2 и +5. За полчаса на Си (Keil uVision 3 котрая оптимизировалась под 8051 ~10 лет) написал ф-н. Все бы хорошо но она занимает 3 К (Flash вполне хватает 64K), но для одной функции (~50 строчек) без делений и умножений (только суммирование и сдвиги) это чересчур. Начал оптимизировать на Си – уменьшилась до 2.3 K, но код стал настолько запутанным что смысл Си как языка верхнего уровня почти пропал. Переписал на ASM ~ 0.7K но уже 300 строчек. Так что получился выигрыш > 4 раз, но времени ушло в раз 6-8 больше. На ARM может лучше компилятор работает, но выигрыш в на 5-10% на asm уж очень мало, либо программа пишется в лоб без всякой оптимизации. На asm программу можно так оптимизировать под конкретное ядро что ни один компилятор не сможет тягаться. Но на мой взгляд на Asm имеет смысл только для узких мест (максимальное быстродействие или если памятью совсем напряг) остальное или хотя каркас на Си.

Похоже, праздник удался

Одно дело - асм 51-го:
[метка:] мнемоника
+ [операнд приемник]
+ [операнд источник]

Другое дело - асм ARM:
[метка:] мнемоника
+ [суффикс типа]
+ [условный суффикс]
+ [операнд приемник]
+ [первый операнд источник]
+ [второй операнд источник]
+ [код операции сдвига второго операнда]
+ [аргумент операции сдвига]

Видите сколько возможностей во втором случае? И далеко не всегда самый оптимальный путь сразу очевиден. Даже для опытного человека

Мне Asm ARM тоже не очень нравится. Но тут как я понял товарищ не от нечего делать спрашивает, наверное нужда заставляет. Я бы, например для ADSP тоже на Си все писал если бы проги не увеличивались в 4-5 раза! А ASM c его многофункциональными командами, модификаторами тоже не подарок.
Пример привел для 8051, потому что были записаны объемы функций для Си и Asm.

А вот тут не факт что вы лучше напишете.
Деление на константу многие компиляторы умеют не хуже человека на асм-е.
Притом в случае с С-ями можно определить эту константу простым define-ом, и
менять хоть сто раз, при перекомпиляции компиллер всё что надо сделает.
А вот в случае с АСМ-овой реализацией надо код переписывать каждый раз.

Хотя согласен что человек всегда может сделать лучше, компактней, быстрее, но дольше.
В конце концов можно ж и от Си идти, скомпилял Си-шный прототип, поглядел что получилось, попробовал оптимизировать.

$О) Классные картинки!

теперь немного цифр.

в неделе 40 часов 1 час 20? = 600? в неделю
у Вас в 6 раз больше 600х6 = 3600?
минусы на 6 недель задержка, про поддержку кода можно забыть.
минимальная партия для выхода в ноль 1500 штук.

Ещё про оптимизацию операций в конвейере вспомнить нелишне (хотя, к размеру кода это отношения и не имеет). У многих процессоров он дли-и-инный, "вручную" всё делать - костьми ляжешь.

Простите, а какой ADSP и какой конкретно С компилер имеются в виду?

ADSP2189M.
Си поддерживаем последним VisualDSP++.

Понятно. Я тоже от С для ADSP-21xx отказался, правда, в 90-х ещё. Плохо там с кодогенерацией всё было... Сейчас не знаю, может, поправили кое-что, но данное семейство процессоров уже не развивается, и средства разработки не совершествуются... Переползайте на блэкфин, у него с этим всё нормально . Правда, самые вычислительно напряжённые процедуры лучше всё-таки на асме писать...

Повторюсь. На asm на мой взгляд разумно писать только вставки критические по времени или если разработчик взял МК в котором памяти меньше чем занимает программа на Си. Т.е. написали 1 раз на asm например ф-н чтения АЦП с какими либо режимами синхронизации (за 1 день), а потом пишем всю обработку на Си (оставшийся месяц). А если памяти программ мало, железо уже есть и переделывать его ни кто не хочет, а прога на Си больше ПП, то хочешь не хочешь нужно будет писать на asm.

P.S. Где это такая зп 20?/час?

Это не зп, точнее, не только она.

у нас вон проблема с С++ на С перейти.
программисты упираются. и я их понимаю.
так как наработанные тоны исходников можно выбросить, а это капитал и время.

Это что - самоцель?
Кому пришло в голову такую задачу поставить?

рассматривается вариант ON-Chip проекта на Mikroblase или похожего.
так вот там С++ нет.