ARM начинающим Опции

[=NIK=]

Мужики. Подскажите плз куда можно почитать по ARM новичку. Я AVR худо-бедно освоил. А вот что такое ARM слабо представляю. Проги писал на асме. Сишник не знаю.

Заранее благодарен.

[iit]

Мужики. Подскажите плз куда можно почитать по ARM новичку. Я AVR худо-бедно освоил. А вот что такое ARM слабо представляю. Проги писал на асме. Сишник не знаю.

Заранее благодарен.

Посмотри на gaw там раньше вступительные статьи были, для поимения представления.

[vzyk]

В ARM'е всё по проще. Там нет ни каких разделений между памятью, регистрах, ROM - всё размещенно в 0..FFFFFFFF адресах. Канечно, никто в ASM зесь не програмирует Только на С.
Рекомендую просто берить PDF кокого то ARM'a, и всё.

[dch]

Только на С.

Без C прохо

[aaarrr]

Канечно, никто в ASM зесь не програмирует  Только на С

Сдрассте! Еще как программируют. Еще напишите, что на ARM только под Linux'ом или WinCE можно работать.

[iit]

Канечно, никто в ASM зесь не програмирует Только на С.

Ну, батенька, прям за живое задели. Кипит мой разум возмущенный.

[Andy Mozzhevilov]

Канечно, никто в ASM зесь не програмирует  Только на С

Сдрассте! Еще как программируют.

И что, для этого есть необходимость, действительно реальная и суровая ?

[Karl]

Хочу написать проект на SAM7S64. До этого работал только с AVR. Какую среду разработки посоветуете? Какие программаторы/отладочные средства (JTAG)? Можно ли сделать программатор/JTAG самому? Отладочный компдект AT91SAM7S64-IAR для меня слишком дорог.

[sergik_vrn]

Хочу написать проект на SAM7S64. До этого работал только с AVR. Какую среду разработки посоветуете? Какие программаторы/отладочные средства (JTAG)? Можно ли сделать программатор/JTAG самому? Отладочный компдект AT91SAM7S64-IAR для меня слишком дорог.

с учетом предыдущей работы на АВР лучше всего, думаю, брать ту среду, в коророй работал раньше (насколько я ничего не понимаю, все уважающие себя компилеры имеют варианты под АРМ). из JTAG мы остановились на MT-Link, компромисс между ценой и качеством, щас вот ждем, пока нам его поставят

[vzn]

Хочу написать проект на SAM7S64. До этого работал только с AVR. Какую среду разработки посоветуете? Какие программаторы/отладочные средства (JTAG)? Можно ли сделать программатор/JTAG самому? Отладочный компдект AT91SAM7S64-IAR для меня слишком дорог.

Компилятор качается с iar.com
Отладчи можна сделать самому.
Схема Wiggler (отладчика) есть на сахаре в проектах. Делается из двух микросхем.
Отладочный комплект может быть например таким
http://www.olimex.com/dev/sam7-p64.html
В россии есть их диллер.

[aaarrr]

И что, для этого есть необходимость, действительно реальная и суровая ?

Представьте себе, бывает. Например, при работе с графикой/звуком или тяжелой периферией (типа fast ethernet). Я не призываю все писать на ASM, но без знания оного даже писание на Ц получается неполноценным.

[sergeeff]

Да прямо сам Atmel продает отладочную систему под SAM. Он снабжен JTAG'ом и IAR компилятором полностью рабочим, но генерирующим код не более 32 kB. Все стоит около 300 евро. Почитай на сайте Atmel'a.

[Dot]

А вот что такое ARM слабо представляю. Проги писал на асме. Сишник не знаю.

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

Это немного напрягает.

[=NIK=]

Вот по делу разговор пошол

Может есть какая-нибудь ссылка где для таких как я почитать все это?
Ну чтобы на пальцах и все доступно?

[Stanislav]

Канечно, никто в ASM зесь не програмирует  Только на С

Сдрассте! Еще как программируют. Еще напишите, что на ARM только под Linux'ом или WinCE можно работать.

Присоединяюсь! Если бы не знающие ассемблера могли только представить себе, чтО может закошмарить компилятор даже в простеньком цикле, они были бы поосторожнее в оценках.
Сдается, что освоение ARM ассемблера после AVR не будет представлять большой сложности.

[Dot]

Ну чтобы на пальцах и все доступно?

The Insider's Guide (~6MB):
http://www.hitex.co.uk/arm/lpc2000book/index.html
(либо сразу по http://www.hitex.co.uk/arm/lpc2000book/lpc-ARM-book_srn.pdf)

Я на эту книжку наткнулся уже после того, как изучил даташиты
Кстати, где-то тут выкладывали ее принтабельный вариант.

[slabnoff]

Кстати, где-то тут выкладывали ее принтабельный вариант.

Если кому надо - зашлю - 4.4 мега в зипе. Но это по филипсовским ARM-ам, правда многие вещи безотносительно филипса. В принципе есть еще arm7tdmi.pdf (1.15 мега в зипе) - описание ядра от фирмы ARM с описанием режимов, ассемблера и растактовки, что называется must have - могу прислать, можно также легко найти в Инете.

С уважением, Андрей Слабнов.

[Andy Mozzhevilov]

И что, для этого есть необходимость, действительно реальная и суровая ?

Представьте себе, бывает. Например, при работе с графикой/звуком или тяжелой периферией (типа fast ethernet). Я не призываю все писать на ASM, но без знания оного даже писание на Ц получается неполноценным.

Так это уже 2 большие разницы. Сравните - писание проекта на асме целиком vs писание на асме только критических мест. Хотя даже второе лучше писать на С (если оно успевает), хотя бы с точки зрения сопровождаемости кода.

[aaarrr]

Так это уже 2 большие разницы. Сравните - писание проекта на асме целиком vs писание на асме только критических мест. Хотя даже второе лучше писать на С (если оно успевает), хотя бы с точки зрения сопровождаемости кода.

Интересно, а на LPC2101 тоже на C будем писать? Вообще-то изначально человек высказался в том смысле, что на АСМ'е здесь вообще никто и ничего не пишет, что не есть правда. А "сопровождаемость" кода вовсе не зависит от того, на каком языке он написан, скорее, это зависит от качества документации и сопровождающего.

[Andy Mozzhevilov]

Так это уже 2 большие разницы. Сравните - писание проекта на асме целиком vs писание на асме только критических мест. Хотя даже второе лучше писать на С (если оно успевает), хотя бы с точки зрения сопровождаемости кода.

Интересно, а на LPC2101 тоже на C будем писать?

Если уж на всякие x51, AVR и младшие пики код прекрасно пишется на Ц, не вижу сколько-нибудь значимых причин, не дающих писать для 2101 на том же Ц.

А "сопровождаемость" кода вовсе не зависит от того, на каком языке он написан, скорее, это зависит от качества документации и сопровождающего.

При прочих равных код на ЯВУ сопровождается лучше, код на ЯВУ под ОС, еще лучше.

[aaarrr]

Если уж на всякие x51, AVR и младшие пики код прекрасно пишется на Ц, не вижу сколько-нибудь значимых причин, не дающих писать для 2101 на том же Ц.

Может быть и прекрасно, да только уж на мелких восьмибитниках ASM сам доктор прописал использовать (я не беру в расчет уродцев с 128к флеш). Ладно, надо завязывать, а то дискуссия планомерно скатывается в оффтоп и религиозную войну...

[Andy Mozzhevilov]

Если уж на всякие x51, AVR и младшие пики код прекрасно пишется на Ц, не вижу сколько-нибудь значимых причин, не дающих писать для 2101 на том же Ц.

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

Какая разница, сколько там флэш.
Эмпирическая оценка разбухания кода Си по сравнениею с асм 1,3-1,5 раз.
Быстродействия примерно столько же. Кочечно, есть и частные случаи.

Ладно, надо завязывать, а то дискуссия планомерно скатывается в оффтоп и религиозную войну...

Ну вот, так всегда, только найдешь тему где можно эмоций да постов понабрать :-)))

[jasper]

Интересно, а про ARM-ы книжки на русском в природе встречаются?

[aaarrr]

Какая разница, сколько там флэш.
Эмпирическая оценка разбухания кода Си по сравнениею с асм 1,3-1,5 раз.
Быстродействия примерно столько же. Кочечно, есть и частные случаи.

Так жизнь состоит сплошь из частных случаев А Ваша оценка в 1,3-1,5 кажется мне несколько заниженной даже для самых общих случаев (раза в 2).

[Andy Mozzhevilov]

Какая разница, сколько там флэш.
Эмпирическая оценка разбухания кода Си по сравнениею с асм 1,3-1,5 раз.
Быстродействия примерно столько же. Кочечно, есть и частные случаи.

Так жизнь состоит сплошь из частных случаев А Ваша оценка в 1,3-1,5 кажется мне несколько заниженной даже для самых общих случаев (раза в 2).

Давайте сделаем тест. Вы предлагаете какой-либо общий случай, например реализация кольцевого буфера FIFO для передатчика UART (вполне себе общая типовая задача для embedded), приводите реализацию на асм для ARM. Я делаю то же самое на Ц. Результаты cравниваем, вычисляем оверхед Ц. Если он больше 1.5 раз, я ставлю ящик пива или перевожу вам деньги для его приобретения. Ы?

[aaarrr]

Давайте сделаем тест. Вы предлагаете какой-либо общий случай, например реализация кольцевого буфера FIFO для передатчика UART (вполне себе общая типовая задача для embedded), приводите реализацию на асм для ARM. Я делаю то же самое на Ц. Результаты cравниваем, вычисляем оверхед Ц. Если он больше 1.5 раз, я ставлю ящик пива или перевожу вам деньги для его приобретения. Ы?

Будете смеяться, но FIFO буферы я тоже пишу на Ц Но если взять другой общий случай, например копирование/заполнение массива, то оверхед будет просто немеренный.

[NickS]

Какая разница, сколько там флэш.
Эмпирическая оценка разбухания кода Си по сравнениею с асм 1,3-1,5 раз.
Быстродействия примерно столько же. Кочечно, есть и частные случаи.

Внесу и я свое замечание на 5 копеек.
Вообще-то как я замечал оценка разбухания кода и соответственно быстродействие оличается в 3-4 раза.
Только сравнивать надо не отдельные функции, а модуль целиком, содержащий большое количество функций.

[Andy Mozzhevilov]

Давайте сделаем тест. Вы предлагаете какой-либо общий случай, например реализация кольцевого буфера FIFO для передатчика UART (вполне себе общая типовая задача для embedded), приводите реализацию на асм для ARM. Я делаю то же самое на Ц. Результаты cравниваем, вычисляем оверхед Ц. Если он больше 1.5 раз, я ставлю ящик пива или перевожу вам деньги для его приобретения. Ы?

Будете смеяться, но FIFO буферы я тоже пишу на Ц Но если взять другой общий случай, например копирование/заполнение массива, то оверхед будет просто немеренный.

Огласите цифры. Давайте пример на асм и описание алгоритма, который нужно реализовать.

[Andy Mozzhevilov]

Какая разница, сколько там флэш.
Эмпирическая оценка разбухания кода Си по сравнениею с асм 1,3-1,5 раз.
Быстродействия примерно столько же. Кочечно, есть и частные случаи.

Внесу и я свое замечание на 5 копеек.
Вообще-то как я замечал оценка разбухания кода и соответственно быстродействие оличается в 3-4 раза.

Это, мягко говоря, неправда.

Только сравнивать надо не отдельные функции, а модуль целиком, содержащий большое количество функций.

При увеличении количества функций все лишь нивелируется, стремясь к среднему значению. Если можно еще найти отдельные локальные места, где на асм можно выиграть 3-4 раза объема или быстродействия по сравнению с Ц, то в большом проекте эти места утонут в море среднестатистических показателей.

[aaarrr]

Огласите цифры. Давайте пример на асм и описание алгоритма, который нужно реализовать.

Да пожалуйста: скопируем массив объемом 8K из пункта А в пункт Б. На АСМе получается огромный выйгрыш за счет использования LDM/STM.

[Andy Mozzhevilov]

Огласите цифры. Давайте пример на асм и описание алгоритма, который нужно реализовать.

Да пожалуйста: скопируем массив объемом 8K из пункта А в пункт Б. На АСМе получается огромный выйгрыш за счет использования LDM/STM.

Выигрыш получится в быстродействии, а не в объеме кода.
В объеме кода как раз получится проигрыш. Потом, давайте добавим в задачу ложку дегдя, сделав переменным размер копируемого блока. Тогда вам уже как минимум нужно будет заботиться о вычислении размера остатка и делать отдельную веточку в алгоритме для докопирования этого остатка, не кратного по размеру блоку используемых регистров. А еще добавить произвольное выравнивание начала блока, а не только по границе 4?
То есть как я и говорил, бывают частные случаи, не более того. Если это критично, можно писать на асме, если это только для самолюбования, то нафиг.

[Виктория]

Огласите цифры. Давайте пример на асм и описание алгоритма, который нужно реализовать.

Да пожалуйста: скопируем массив объемом 8K из пункта А в пункт Б. На АСМе получается огромный выйгрыш за счет использования LDM/STM.

Выигрыш получится в быстродействии, а не в объеме кода.
В объеме кода как раз получится проигрыш. Потом, давайте добавим в задачу ложку дегдя, сделав переменным размер копируемого блока. Тогда вам уже как минимум нужно будет заботиться о вычислении размера остатка и делать отдельную веточку в алгоритме для докопирования этого остатка, не кратного по размеру блоку используемых регистров. А еще добавить произвольное выравнивание начала блока, а не только по границе 4?
То есть как я и говорил, бывают частные случаи, не более того. Если это критично, можно писать на асме, если это только для самолюбования, то нафиг.

Еще одна ложка - скорее всего для исходной постановке задачи (8К и const) компилятор сам сооптимизирует код (те же LDM/STM).

[aaarrr]

Выигрыш получится в быстродействии, а не в объеме кода.
В объеме кода как раз получится проигрыш. Потом, давайте добавим в задачу ложку дегдя, сделав переменным размер копируемого блока. Тогда вам уже как минимум нужно будет заботиться о вычислении размера остатка и делать отдельную веточку в алгоритме для докопирования этого остатка, не кратного по размеру блоку используемых регистров. А еще добавить произвольное выравнивание начала блока, а не только по границе 4?
То есть как я и говорил, бывают частные случаи, не более того. Если это критично, можно писать на асме, если это только для самолюбования, то нафиг.

Дык все верно, только эффективность нельзя оценивать по небольшому фрагменту, следует взять достаточно большой проект (не менее 3000-4000 Ц строк), написать его на Ц и АСМ, и сравнить. Вот только заниматься этим никто не будет...
З.Ы. Прикола ради попробовал табличный CRC16 - получился выйгрыш на 10% по скорости и 30% по объему

[aaarrr]

Еще одна ложка - скорее всего для исходной постановке задачи (8К и const) компилятор сам сооптимизирует код (те же LDM/STM).

Где Вы увидели const? И покажите мне такой компилятор, который вместо понятного ему вызова тормозного memcpy станет извращатся с LDM/STM.

[Виктория]

Еще одна ложка - скорее всего для исходной постановке задачи (8К и const) компилятор сам сооптимизирует код (те же LDM/STM).

Где Вы увидели const? И покажите мне такой компилятор, который вместо понятного ему вызова тормозного memcpy станет извращатся с LDM/STM.

1) длина массива=const

2) Это не только от компилятора зависит, от программиста тож. Чувствовать надо (или знать), где он может сооптимизировать и при каких условиях.

[aaarrr]

1) длина массива=const

2) Это не только от компилятора зависит, от программиста тож. Чувствовать надо (или знать), где он может сооптимизировать и при каких условиях.

Так речь не об особенностях оптимизации компилятора, а о том, что конструкцию с LDM/STM на Ц вообще реализовать не получится.

[Виктория]

Так речь не об особенностях оптимизации компилятора, а о том, что  конструкцию с LDM/STM на Ц вообще реализовать не получится.

Не понимает...
Если, последовательно (не мешая в кучу). Функция memcpy (кстати чем она Вам не понравилась? Вы уверены, что там не через LDM/STM?) добавляет (как всякая функция) некие накладные расходы по передаче параметров. Мало-мальские приличные компиляторы для оптимизации при типичных ситуациях (например, длина массива - константа, массивы - глобальные переменные) заменяют вызов функции inline кодом, обходясь тем самым без вызова функции memcpy

[aaarrr]

Так речь не об особенностях оптимизации компилятора, а о том, что  конструкцию с LDM/STM на Ц вообще реализовать не получится.

Не понимает...
Если, последовательно (не мешая в кучу). Функция memcpy (кстати чем она Вам не понравилась? Вы уверены, что там не через LDM/STM?) добавляет (как всякая функция) некие накладные расходы по передаче параметров. Мало-мальские приличные компиляторы для оптимизации при типичных ситуациях (например, длина массива - константа, массивы - глобальные переменные) заменяют вызов функции inline кодом, обходясь тем самым без вызова функции memcpy

Не понимаю!
1. Уверен, что не использует. Оперирует максимум только словами.
2. Еще раз прошу: покажите мне компилятор, который ведет себя хотя бы близко так, как Вы описываете.

[Виктория]

Тогда еще раз условия задачи: процессор - ?, размер элемента массива - байт? и т.п.

[Andy Mozzhevilov]

Не понимаю!
1. Уверен, что не использует. Оперирует максимум только словами.

IAR оптимизирует словами.

2. Еще раз прошу: покажите мне компилятор, который ведет себя хотя бы близко так, как Вы описываете.

А нужно? Это весьма частный случай.

[aaarrr]

А нужно? Это весьма частный случай.

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

[Andy Mozzhevilov]

Выигрыш получится в То есть как я и говорил, бывают частные случаи, не более того. Если это критично, можно писать на асме, если это только для самолюбования, то нафиг.

Дык все верно, только эффективность нельзя оценивать по небольшому фрагменту, следует взять достаточно большой проект (не менее 3000-4000 Ц строк), написать его на Ц и АСМ, и сравнить. Вот только заниматься этим никто не будет...

Специально возможно и нет. Но возьмите типичную структуру кода. Циклы, управляющие структуры, функции (подпрограммы). Посмотрите, как эти структуры реализует компилятор, и насколько оптимальнее это можно сделать на асм. В завистимотси от процессора/компилятора проигрыш Ц будет от 0 до 50% в более или менее общих случаях. Все частные случаи накладывают сильные ограничения, и поэтому эти частные случаи трудносопровождаемы, шаг вправо, шаг влево - расстрел. Тот же LDM/STM потребует дополнительных телодвижений при отсутствия выравнивания на 4 и любого количества байт в блоке. И вся оптимальность тут уже начинает идти лесом на мелких блоках. То есть удел асма - вставки там, где действительно нужно выжать максимум быстродейтсвия, таких мест не очень много.

З.Ы. Прикола ради попробовал табличный CRC16 - получился выйгрыш на 10% по скорости и 30% по объему

То есть как я и говорил, 1.3 раза по коду.

[aaarrr]

Тогда еще раз условия задачи: процессор - ?, размер элемента массива - байт? и т.п.

Хорошо. Условия задачи:
1. Процессор: ARM7
2. Размер элемента массива: 4 байта (слово)
3. Количество элементов: 2048
4. Источник и приемник выравнены по границе слова (ложка дёгтя здесь
отсутствует, но можно добавить - 4 байта из 8192 картину не испортят)
5. Оптимизация на скорость

Попробуйте решить это на Ц и сравните с АСМ

[Виктория]

А нужно? Это весьма частный случай.

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

Опять слишком "жесткое" утверждение. Поймите и Вы, я тоже не цепляюсь именно к этому примеру. Но Ваши категоричные утверждения
Вы хоть знаете где Ваш компилятор (именно тот с которым Вы работаете) делает оптимизацию (и какие приемы лучше при этом использовать). Ну хотя бы такую классику ++j или j++. Или сравниваете C-программы и Asm-прог только по конечному результату?

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

От своей реплики с условиями задачи не отказываюсь

[Виктория]

Хм, издержки реального времени (почти одновременные ответы).

Условия принимаю.

[aaarrr]

Опять слишком "жесткое" утверждение. Поймите и Вы, я тоже не цепляюсь именно к этому примеру. Но Ваши категоричные утверждения 
Вы хоть знаете где Ваш компилятор (именно тот  с которым Вы работаете) делает оптимизацию (и какие приемы лучше при этом использовать). Ну хотя бы такую классику ++j или j++.  Или сравниваете C-программы и Asm-прог только по конечному результату?

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

От своей реплики с условиями задачи не отказываюсь 

Поверьте, я прекрасно знаю, где и как работает оптимизация у моего компилятора. Когда-то угробил прилично времени на действия типа: модифицируем код->компилируем->дизассемблируем->смотрим, где накосячено.

А приведенная мной задача не решается на Ц оптимально.

[Виктория]

Прерываюсь на какое-то время. Пора домой

[Dot]

Ничего себе -- " ARM начинающим"!

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

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

Если заранее найти такие места и написать их на асме, то код станет гораздо "сопровождаемее".

[aaarrr]

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

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

[NickS]

Какая разница, сколько там флэш.
Эмпирическая оценка разбухания кода Си по сравнениею с асм 1,3-1,5 раз.
Быстродействия примерно столько же. Кочечно, есть и частные случаи.

Внесу и я свое замечание на 5 копеек.
Вообще-то как я замечал оценка разбухания кода и соответственно быстродействие оличается в 3-4 раза.

Это, мягко говоря, неправда.

Только сравнивать надо не отдельные функции, а модуль целиком, содержащий большое количество функций.

При увеличении количества функций все лишь нивелируется, стремясь к среднему значению. Если можно еще найти отдельные локальные места, где на асм можно выиграть 3-4 раза объема или быстродействия по сравнению с Ц, то в большом проекте эти места утонут в море среднестатистических показателей.

Судя по всему вы не писали достаточно большие проекты на ASM.
У меня, конечно, довольно редко воникает проект продублированный на С и ASM. Однако, например для кодека G.723.1 переписывание только базовых функций на ASM привело к уменьшению времени обработки одного фрейма с 200мс до 25, что соответствует примерно 10 кратному ускорению времени выполнения. Для обработчика обмена по USB выигрышь по скорости обработки выросло в 4 раза.

И как раз чем бльше проект, тем заметнее разница.
Если на отдельных простых функциях разница составляет 30% то на сложных функциях, а уж тем более больших проектах разница достигает 3-4 каратного превосходства.

И чтобы не быть совсем голословным:

Вы предлагали сравнить на реальном проекте.

У меня недавно был проект часть которого также была выполненый на С и ASM.

Это real FFT.
На котором также легко демонстрируется трехкратное превосходство ASM над С.
Итак:
Есть входной масив данных int16 Data[2048];
Так же есть входной оконный масив int16 WIN[2048];
Наебходимо выполнить следующее:
Первоначально поэлементно умножить елемент данных на елемент окна

Data[i]=Data[i]*WIN[i]/65536;

Далее выполнить реальное преобразование фурье по 2048 точкам.
И получить квадкат абсолютного значения по получившимся комплексным отсчетам.
ABS= RE*RE+Im*Im;

Выходной массив это int32 Abs[1024] расположен на месте входного массива данных Data[2048].

пример на ASM прилагаю:

Он занимает 4К памяти данных, и во Flash 4К под окно, 4К под служебные таблицы и совсем чуть-чуть под программы.
Один цикл вычислений занимает примерно 500 000 цикло для 7TDMI.
На С аналогичная программ требовала примерно в 3 раза больше.

Если вы полагаете, что сможете получить аналогичные ( в приделах 30% ) результаты на С, покажите это.

В принципе дело достаточное простое для С.

Умножение на окно и авсолютное значение - функции достаточно простые.
А real FFT предлагается в довольно большом количестве библиотек если лень писать самому.

Прикрепленные файлы

 fft_sample.zip ( 25.19 килобайт ) Кол-во скачиваний: 158

 

[Andy Mozzhevilov]

Тогда еще раз условия задачи: процессор - ?, размер элемента массива - байт? и т.п.

Хорошо. Условия задачи:
1. Процессор: ARM7
2. Размер элемента массива: 4 байта (слово)
3. Количество элементов: 2048
4. Источник и приемник выравнены по границе слова (ложка дёгтя здесь
отсутствует, но можно добавить - 4 байта из 8192 картину не испортят)
5. Оптимизация на скорость

Попробуйте решить это на Ц и сравните с АСМ

Опубликуйте асм-код

[Andy Mozzhevilov]

Ничего себе  -- " ARM начинающим"!

так чтобы жизнь медом не казалась

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

При правильном выборе процессора как правило все успевает. А то иногда встречаются люди, которые mp3 хотят программно делать на х51. Или USB или Ethernet генерить программно.

Поменяли компилятор (апгрейд версии,

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

заказчик вдруг решил перейти на другой,

Заказчику глубоко фиолетово на каком компиляторе решена его проблема.
Он, возможно даже не знает слова компилятор.

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

Никто не пишет программы в притык к 100% производительности процессора,
если это так, то тут ошибка в ДНК.

Если заранее найти такие места и написать их на асме, то код станет  гораздо "сопровождаемее".

какие места? как определить, что вот это место такое, а вот это место - не такое?

[Andy Mozzhevilov]

Судя по всему вы не писали достаточно большие проекты на ASM.
У меня, конечно,  довольно редко воникает проект продублированный на С и ASM. Однако, например для кодека G.723.1  переписывание только базовых функций  на ASM  привело к уменьшению времени обработки одного фрейма с 200мс до 25, что соответствует примерно 10 кратному ускорению времени выполнения. Для обработчика обмена по USB выигрышь по скорости обработки выросло в 4 раза.

Я не работаю в этих областях, и к сожалению не могу прокомментировать данные цифры. Но 200 мс и 25 вообще выглядит весьма странно.

Умножение на окно и авсолютное значение - функции достаточно простые.

Да, простые, поэтому и писание их заняло не более получаса, с учетом настройки опций этого тестового проекта и приведения ваших исходников к синтаксису IAR. Итак, IAR 4.30:
Функция window, ваш вариант:

Код

;    GLOBAL    window
    PUBLIC    window
window
    stmfd    r13!,{r2-r3,r14}
    ldr  r14,=WINTABLE
    mov    r1,r1,lsl #1
win_l0
    ldrsh  r2,[r14],#2;WIN[i]
    ldrsh  r3,[r0]  ;Buf[i]
    mul  r3,r2,r3
    mov  r3,r3,asr #15
    strh  r3,[r0],#2;Buf[i]
    subs    r1,r1,#1
    bgt    win_l0

    ldmfd    r13!,{r2-r3,pc}

Функция window, мой вариант:

Код

static const signed short Rfft_c_wintbl[2048] = {...}

void window_c  (signed short *Buf, int Len)
{
   const signed short *win = Rfft_c_wintbl;

   do
   {
       *Buf = (*Buf * *win) /65536;
       Buf++;
       win++;
   } while (--Len);
}

143          void window_c  (signed short *Buf, int Len)
   144          {
   145              const signed short *win = Rfft_c_wintbl;
  \                     window_c:
  \   00000000   24209FE5           LDR         R2,??window_c_0  ;; ??Rfft_c_wintbl
   146
   147              do
   148              {
   149                  *Buf = (*Buf * *win) /65536;
  \                     ??window_c_1:
  \   00000004   F030D0E1           LDRSH       R3,[R0, #+0]
  \   00000008   ........           LDRSH       R12,[R2], #+0x2
  \   0000000C   9C0303E0           MUL         R3,R12,R3
  \   00000010   C3C7A0E1           MOV         R12,R3, ASR #+0xF
  \   00000014   2C3883E0           ADD         R3,R3,R12, LSR #+0x10
  \   00000018   4338A0E1           MOV         R3,R3, ASR #+0x10
  \   0000001C   ........           STRH        R3,[R0], #+0x2
   150                  Buf++;
   151                  win++;
   152              } while (--Len);
  \   00000020   011051E2           SUBS        R1,R1,#+0x1
  \   00000024   F6FFFF1A           BNE         ??window_c_1
   153          }
  \   00000028   0EF0A0E1           MOV         PC,LR            ;; return
  \                     ??window_c_0:
  \   0000002C   ........           DC32        ??Rfft_c_wintbl

Все тело цикла практически одинаково, за исключением деления на 65536,
что в вашем варианте выглядит просто как арифметический сдвиг

Код

    mov  r3,r3,asr #15

а в варианте компилятора, как

Код

  \   00000010   C3C7A0E1           MOV         R12,R3, ASR #+0xF
  \   00000014   2C3883E0           ADD         R3,R3,R12, LSR #+0x10
  \   00000018   4338A0E1           MOV         R3,R3, ASR #+0x10

Что по сути правильно, поскольку в вашем варианте при делении отрицательного числа никогда не будет получен 0, максимум -1. В общем, округление результата будет несколько не туда и в разные стороны для положительных и отрицательных чисел. Возможно, в вашем приложении это качественно и не сказывается на окончательный результат, но тем не менее, в ТЗ было прописано деление.

Далее, функция abs, ваша

Код

abs_l0
    ldrsh  r2,[r0];Buf[i]
    mul  r3,r2,r2
    ldrsh  r2,[r0,#2];Buf[i]
    mla  r3,r2,r2,r3
    mov  r3,r3,asr #14
    str  r3,[r0],#4;Buf[i]
    subs    r1,r1,#1
    bgt    abs_l0

моя

Код

void absr_c    (short *Buf, int Len)
{
   unsigned int *p_out = (unsigned int *)Buf;

   do
   {
     int temp = *Buf * *Buf;
     Buf++;
     temp += *Buf * *Buf;
     Buf++;
     *p_out++ = temp;
   } while (--Len);
}

   155          void absr_c    (short *Buf, int Len)
   156          {
   157              unsigned int *p_out = (unsigned int *)Buf;
  \                     absr_c:
  \   00000000   0020A0E1           MOV         R2,R0
   158          
   159              do
   160              {
   161                int temp = *Buf * *Buf;
  \                     ??absr_c_0:
  \   00000004   F030D0E1           LDRSH       R3,[R0, #+0]
  \   00000008   93030CE0           MUL         R12,R3,R3
   162                Buf++;
   163                temp += *Buf * *Buf;
  \   0000000C   F230F0E1           LDRSH       R3,[R0, #+0x2]!
  \   00000010   93C32CE0           MLA         R12,R3,R3,R12
   164                Buf++;
  \   00000014   020080E2           ADD         R0,R0,#+0x2
   165                *p_out++ = temp;
  \   00000018   ........           STR         R12,[R2], #+0x4
   166              } while (--Len);
  \   0000001C   011051E2           SUBS        R1,R1,#+0x1
  \   00000020   F7FFFF1A           BNE         ??absr_c_0
   167          }
  \   00000024   0EF0A0E1           MOV         PC,LR            ;; return

То есть издержки Ц - дополнительная команда ADD R0,R0,#+0x2.
Кроме того, у вас там есть масштабирование результата mov r3,r3,asr #14
хотя по ТЗ это описано не было. При добавлении масштабирования код для этой операции создается такой же, как и в верхнем примере.

А real FFT предлагается в довольно большом количестве библиотек если лень писать самому.

Это уже не так быстро, а поскольку я это делаю в рабочее время, то я возьму таймаут для написание этих функци и попробую протестировать на реальном железе. Впрочем, скоро не обещаю.

[sergeeff]

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

[NickS]

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

[dxp]

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

Зато эти функции - типовые для задач, решаемых на МК. В отличие от FFT, которая есть уже весьма специальная задача, кои часто решают на более специальных процессорах, нежели АРМ. И в типовом проекте на МК удельный вес функций типа FFT исчезающе мал. Есть подозрение, что большинству пользователей АРМ (да и других МК) не приходится с этим иметь дело. И если уж этот специальный случай не оправдал у Вас себя на С, то, как же сказали, его можно и на асме реализовать. Но это не повод и не причина писать на асме все. А эффективность кодогенерации С компилятора, ихмо, была продемонстрирована с блеском.

[NickS]

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

Зато эти функции - типовые для задач, решаемых на МК. В отличие от FFT, которая есть уже весьма специальная задача, кои часто решают на более специальных процессорах, нежели АРМ. И в типовом проекте на МК удельный вес функций типа FFT исчезающе мал. Есть подозрение, что большинству пользователей АРМ (да и других МК) не приходится с этим иметь дело. И если уж этот специальный случай не оправдал у Вас себя на С, то, как же сказали, его можно и на асме реализовать. Но это не повод и не причина писать на асме все. А эффективность кодогенерации С компилятора, ихмо, была продемонстрирована с блеском.

Эти функции как раз не типовые.
Большинство функций которые я применяю значительно сложнее.
От вывода на экран и обработки кнопок до алгоритма работы.
Это очень простые функции занимающие несколько строк в исходном тексте.
В большинстве своем функции нанимают в среднем около сотни строк.
В качестве примера достаточно сложной функции и используется FFT. Для меня это пример который у меня реализован и на С и на ASM и разницу здесь я знаю.
А на любой достаточно сложной функции разница станет существенной.

А поскольку тестами утруждаться никто не хочет и делает проверку на примитивных функциях и возникает легенда об высокой эффективности С.
Хотя это не так.

Можете посмотреть сами взяв функцию или модуль хотя бы в несколько сотен строк.

[Andy Mozzhevilov]

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

Каждая функция в конечном итоге состоит из каких-то элементарных действий. Если на элементарные действия Ц дает оверхед на 30% (к примеру), то с чего вдруг вы считаете, что при увеличении количества этих действий вдруг произойдет рост неэффективности Ц в геометрической прогресии?

В большинстве своем функции нанимают в среднем около сотни строк.
В качестве примера достаточно сложной функции и используется FFT. Для меня это пример который у меня реализован и на С и на ASM и разницу здесь я знаю.

Так приведите пример на Ц, я его хотя бы откомпилирую, чтобы не писать самому. Хотя бы посмотреть, откуда там у оверхеда ноги растут.

А на любой достаточно сложной функции разница станет существенной.

Если вы имеете большой опыт сравнения, то скажите за счет чего?

А поскольку тестами утруждаться никто не хочет и делает проверку на примитивных функциях и возникает легенда об высокой эффективности С.
Хотя это не так.
Можете посмотреть сами взяв функцию или модуль хотя бы в несколько сотен строк.

Брали, смотрели листинг после компилятора. Да, где-то можно сделать чуть эффективнее, но как правило не намного. А некоторые виды оптимизации, которые выполняет компилятор - руками делать на ассемблере, свихнуться можно.

[aaarrr]

Опубликуйте асм-код

Пожалуйста:

Код

copy0
    stmfd    sp!, {r4-r9, r14}
    mov  r2, #0x80
copy0_0
    ldmia    r0!, {r3-r9, r12}
    stmia    r1!, {r3-r9, r12}
    ldmia    r0!, {r3-r9, r12}
    stmia    r1!, {r3-r9, r12}
    ldmia    r0!, {r3-r9, r12}
    stmia    r1!, {r3-r9, r12}
    ldmia    r0!, {r3-r9, r12}
    stmia    r1!, {r3-r9, r12}
    subs    r2, r2, #0x01
    bne  copy0_0
    ldmfd    sp!, {r4-r9, pc}

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

[Виктория]

To aaarrr
Весь день I-neta не было (и IARa в том числе). Поэтому пример на подвернувшемся GNU-шном Си (из тех, что вполне ничего). В общем то это только идея, которую можно и дальше продвинуть (соопитимизировать). Кстати, у Andy Mozzhevilov тоже можно дальше сооптимизировать, если уж это так необходимо.
Итак множественная загрузка:

struct m8 { unsigned long w[8]; };

struct m8 a[128];
struct m8 b[128];

void copy0(register struct m8 *pa, register struct m8 *pb)
{register int i;
for(i=128; i!=0; --i)
  *pb++=*pa++;
}


void main()
{
  copy0(a,;       
}

и полностью выход на асме (чтоб без обмана)

.file "prim.c"
.text
.align 2
.global copy0
.type copy0, %function
copy0:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
stmfd sp!, {r4, r5, r6, lr}
mov r5, r0
mov r4, r1
mov r6, #128
.L6:
mov lr, r4
mov ip, r5
ldmia ip!, {r0, r1, r2, r3}
stmia lr!, {r0, r1, r2, r3}
ldmia ip, {r0, r1, r2, r3}
stmia lr, {r0, r1, r2, r3}
add r5, r5, #32
add r4, r4, #32
subs r6, r6, #1
ldmeqfd sp!, {r4, r5, r6, pc}
b .L6
.size copy0, .-copy0
.align 2
.global main
.type main, %function
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 1, uses_anonymous_args = 0
mov ip, sp
stmfd sp!, {fp, ip, lr, pc}
sub fp, ip, #4
ldr r0, .L10
ldr r1, .L10+4
bl copy0
ldmea fp, {fp, sp, pc}
.L11:
.align 2
.L10:
.word a
.word b
.size main, .-main
.comm a, 4096, 32
.comm b, 4096, 32
.ident "GCC: (GNU) 3.3.1"

командная строка компилятора

arm-uclibc-gcc.exe -S -mcpu=arm7tdmi -O -o oops.s prim.c

Прощаюсь до завтра

[aaarrr]

Круто, только write-back не учитывается и выход кривоват . Что интересно, ADS 1.2 городит такую же фигню, но с более прямым циклом.

[VladislavS]

То же от IAR. Оценивать хорошо это или плохо не бурусь.

ARM

Код

a:
     DS8 4096
`b`:
     DS8 4096

copy0:
     STMDB       SP!,{R4-R11}      ;; Push
     MOV         R2,#+0x80
??copy0_0:
     MOV         R3,R1
     MOV         R12,R0
     LDMIA       R12,{R4-R11}
     STMIA       R3,{R4-R11}
     ADD         R0,R0,#+0x20
     ADD         R1,R1,#+0x20
     SUBS        R2,R2,#+0x1
     BNE         ??copy0_0
     LDMIA       SP!,{R4-R11}      ;; Pop
     BX          LR                ;; return

main:
      STR         LR,[SP, #-4]!    ;; Push
      LDR         R0,??main_0      ;; a
      ADD         R1,R0,#+0x1000
      BL          copy0
      LDR         LR,[SP], #+0x4    ;; Pop
      BX          LR                ;; return
??main_0:
      DC32        a

Thumb

Код

a:
      DS8 4096
`b`:
      DS8 4096
      PUSH        {R4,LR}
      MOV         R2,#+0x80
??copy0_0:
      MOV         R4,#+0x20
??copy0_1:
      SUB         R4,R4,#+0x4
      LDR         R3,[R0, R4]
      STR         R3,[R1, R4]
      BNE         ??copy0_1
      ADD         R0,#+0x20
      ADD         R1,#+0x20
      SUB         R2,R2,#+0x1
      BNE         ??copy0_0
      POP         {R4}
      POP         {R0}
      BX          R0                ;; return

main:
       PUSH        {LR}
       LDR         R0,??main_0       ;; a
       MOV         R1,#+0x80
       LSL         R1,R1,#+0x5       ;; #+0x1000
       ADD         R1,R0,R1
       BL          copy0

       POP         {R0}
       BX          R0                ;; return
       NOP        
??main_0:
       DC32        a

[iit]

А что, писание на асме это "западло"?
Я все проекты делаю на асме, потому как видеть что творит С с кодом сил не хватает.
В чем С дает выигрыш?
Знаю начнете говорить о времени разработки, о переносимости с одного компилятора на другой, так это все ерунда.
За время что я работаю у меня накопилось куча функций, которые переходят из одного проекта в другой без изменений (типа арифметика, УАРТ и т.п.)
А при переходе с одного компилятора на другой (при том же процессоре) для асм в основном заголовочные файлы меняются ( a equ 10, или equ a,10) - это не долго. Да и зачем на асме переходить из компилера в компилер? За мою практику такой неизбежной необходимости не возникало.
Засада конечно переносить проект с одной архитектуры на другую, но для меня "лучше день потерять и за полчаса долеьтеть".
И вообще причем тут крылья - главное хвост!

[Виктория]

To aaarrr

Больше сооптимизировать не удалось!
Но, по крайней мере компилятор использует ldm/stm. Вообще в какой-то из функций bcopy или memcpy они тоже должны использоваться (или у Вас есть исходники memcpy???) и может быть более оптимально (с большим числом одновременно загружаемых регистров, без дополнительной перезагрузки в цикле и т.п.).

Действия же компилятора в приведенном примере объясняются фиксированным распределением регистров процессора по функциям (например, в качестве указателей он выбирает, в первую очередь, lr, ip; параметры функции - r0,r1,... и т.п. ). Причем для разных компиляторов (а уж тем более процессоров это может быть по разному).

Невнимательно прочитала последние сообщения. Конечно, пример от VladislavS для IAR - почти идеально

Зато достоинства GNU компилятора (здесь немного ) вот в этом

Hardware Models and Configurations.
AMD 29K Options
ARC Options...78
ARM/StrongARM Options ........................78
ARM THUMB Options ..........83
Clipper Options .............85
DEC Alpha Options ..........85
Hitachi H8/300 Options ..............89
Hitachi SH Options ....................90
HPPA Options.............................90
IBM RS/6000 and PowerPC Options......................92
IBM RT Options .........................101
Intel x86 Options........................102
Intel 960 Options...........................105
Matsushita MN10200 Options ...................107
Matsushita MN10300/AM33 Options .....................107
MIPS Options..................................107
Mitsubishi D10V Options .......................112
Mitsubishi M32R/D/X Options..................................113
Motorola 68000 Options .......................................................114
Motorola 88000 Options ......................................................116
NEC V850 Options .................................119
SPARC Options ....................120
System V Options .........................................124

Это, в какой-то степени, и ответ всем asm-программерам
Переход к новому типу МП происходит с более грамотных позиций. И еще - программирование на Си - использование более высокой технологии, которая в общем случае далее более качественный продукт с меньшими трудозатратами. Пример: кто как может обед разогревать на работе - на костре, кипятильником или в микроволновке. Извините, за легкий offtopic.

[iosifk]

To aaarrr


Зато достоинства GNU компилятора (здесь немного  ) вот в этом

Hardware Models and Configurations.
AMD 29K Options
ARC Options...78
ARM/StrongARM Options ........................78
ARM THUMB Options ..........83
Clipper Options .............85
DEC Alpha Options ..........85
Hitachi H8/300 Options ..............89
Hitachi SH Options ....................90
HPPA Options.............................90
IBM RS/6000 and PowerPC Options......................92
IBM RT Options .........................101
Intel x86 Options........................102
Intel 960 Options...........................105
Matsushita MN10200 Options ...................107
Matsushita MN10300/AM33 Options .....................107
MIPS Options..................................107
Mitsubishi D10V Options .......................112
Mitsubishi M32R/D/X Options..................................113
Motorola 68000 Options .......................................................114
Motorola 88000 Options ......................................................116
NEC V850 Options .................................119
SPARC Options ....................120
System V Options .........................................124

Это, в какой-то степени, и ответ всем asm-программерам

Как получены эти цифры?
Прошу ответить болле подробно. Меня интересует сравнение ARM и V850.

[Andy Mozzhevilov]

А что, писание на асме это "западло"?

в общем да

Я все проекты делаю на асме, потому как видеть что творит С с кодом сил не хватает.

Много вы видели? Те листинги, что приводились выше, чем ужасают?

В чем С дает выигрыш?
Знаю начнете говорить о времени разработки, о переносимости с одного компилятора на другой, так это все ерунда.

Не ерунда. Особенно о времени разработки и сопровождаемости.

За время что я работаю у меня накопилось куча функций, которые переходят из одного проекта в другой без изменений (типа арифметика, УАРТ и т.п.)
А при переходе с одного компилятора на другой (при том же процессоре) для асм в основном заголовочные файлы меняются ( a equ 10, или equ a,10) - это не долго. Да и зачем на асме переходить из компилера в компилер? За мою практику такой неизбежной необходимости не возникало.
Засада конечно переносить проект с одной архитектуры на другую, но для меня "лучше день потерять и за полчаса долеьтеть".
И вообще причем тут крылья - главное хвост!

а вы знаете, что такое CVS, или SVN? Или тоже неприемлете, покуда нафиг не нужно?

[Виктория]

Quote - это лист содержания описания компилятора (цифры - номера страниц)
Приношу извинения.

Приведено для иллюстрации, что в рамках одного компилятора я могу использовать различные МС (из этого списка)

[Andy Mozzhevilov]

То же от IAR. Оценивать хорошо это или плохо не бурусь.

Это какой версией компилятора компилировалось? Какие опции оптимизации были установлены?

[aaarrr]

To aaarrr

Больше сооптимизировать не удалось! 
Но, по крайней мере компилятор использует ldm/stm. Вообще в какой-то из функций bcopy или memcpy они тоже должны использоваться (или у Вас есть исходники memcpy???) и может быть более оптимально (с большим числом одновременно загружаемых регистров, без дополнительной перезагрузки в цикле и т.п.).

Да, memcpy умнее написана, хотя её ничего не стоит посадить в
лужу невыравненным адресом. И написана она, конечно, на АСМе

Это, в какой-то степени, и ответ всем asm-программерам 
Переход к новому типу МП происходит с более грамотных позиций. И еще - программирование на Си - использование более высокой технологии, которая в общем случае далее более качественный продукт с меньшими трудозатратами. Пример:  кто как может обед разогревать на работе - на костре, кипятильником или в микроволновке. Извините, за легкий offtopic.

Насчет качества продукта и высоких технологий - не надо рассказывать сказки: качество, в общем случае, ниже. Просто использование ЯВУ позволяет использовать менее квалифицированную рабсилу, и только.

P.S. Всю эту дрянь из микроволновки я не ем ©

[Виктория]

To [/B]aaarrr[B]

Да, memcpy умнее написана, хотя её ничего не стоит посадить в
лужу невыравненным адресом. И написана она, конечно, на АСМе

Разумеется на asm-e, кто же спорит. Исходника нету?

Насчет качества продукта и высоких технологий - не надо рассказывать сказки: качество, в общем случае, ниже. Просто использование ЯВУ позволяет использовать менее квалифицированную рабсилу, и только.

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

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

[Andy Mozzhevilov]

To aaarrr

Больше сооптимизировать не удалось! 
Но, по крайней мере компилятор использует ldm/stm. Вообще в какой-то из функций bcopy или memcpy они тоже должны использоваться (или у Вас есть исходники memcpy???) и может быть более оптимально (с большим числом одновременно загружаемых регистров, без дополнительной перезагрузки в цикле и т.п.).

Да, memcpy умнее написана, хотя её ничего не стоит посадить в
лужу невыравненным адресом.

Точно также, как и вашу асмовскую функцию. Только memcpy это точно все корректно отыграет, пусть даже создав менее оптимальный код, копирующий байтами, а не словами. А использование вашей функции с невыровненными адресами приведет к непредсказуемым эффектам.

И написана она, конечно, на АСМе

Например, в IAR memcpy написана нак inline функция в string.h

Код

   #pragma inline
   void *memcpy(void *s1, const void *s2, size_t n)
     /* Copied from memcpy.c */
   {       /* copy char s2[n] to s1[n] in any order */
     char *su1 = (char *)s1;
     const char *su2 = (const char *)s2;
 
     for (; 0 < n; ++su1, ++su2, --n)
       *su1 = *su2;
     return (s1);
   }

Насчет качества продукта и высоких технологий - не надо рассказывать сказки: качество, в общем случае, ниже. Просто использование ЯВУ позволяет использовать менее квалифицированную рабсилу, и только.

Вы серьезно полагаете, что квалификация программиста тем выше, чем более низкоуровненый язык он использует?

[aaarrr]

Точно также, как и вашу асмовскую функцию. Только memcpy это точно все корректно отыграет, пусть даже создав менее оптимальный код, копирующий байтами, а не словами. А использование вашей функции с невыровненными адресами приведет к непредсказуемым эффектам.

А кто ее будет так использовать? Ежели это моя функция, то вызывать её буду только я и правильно.

Например, в IAR memcpy написана нак inline функция в string.h

Код

   #pragma inline
   void *memcpy(void *s1, const void *s2, size_t n)
     /* Copied from memcpy.c */
   {       /* copy char s2[n] to s1[n] in any order */
     char *su1 = (char *)s1;
     const char *su2 = (const char *)s2;
 
     for (; 0 < n; ++su1, ++su2, --n)
       *su1 = *su2;
     return (s1);
   }

Ужасно! Всегда считал IAR кривым компилером.

Вы серьезно полагаете, что квалификация программиста тем выше, чем более низкоуровненый язык он использует?

Нет, я считаю, что квалификация программиста тем ниже, чем более низкоуровневый язык он не способен понять.

[Виктория]

Хм, а в обратную сторону (повышения уровня)? Разве это не верно?

[Виктория]

Добавление к квалификации и молодежного сленга "глючный компилятор"
Файл внизу (переименован из string2.h, GNU C)

Прикрепленные файлы

 string2.txt ( 43.03 килобайт ) Кол-во скачиваний: 72

 

[Ken@t]

Ваш креатив - образчик мысли, слога,
До Вас такого точно не писали!
Вам будет зачтено пред ликом Бога,
Что Вы его для нас публиковали...


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

Что в сухом остатке
1. Сравнение кода генерируемого компилятором
2. Флейм.
3. Совместное использование асм и С.

Впрочем об этом давно было известно.

[aaarrr]

Добавление к квалификации и молодежного сленга "глючный компилятор"

И что Вы хотите этим сказать? Что GNU дОлжно рассматривать как референсный компилер что ли?

[Виктория]

Добавление к теме о квалификации (и против молодежного сленга "глючный компилятор" )

[aaarrr]

Добавление к теме о квалификации

Может быть поясните, что Вы имели в виду?

и против молодежного сленга "глючный компилятор"

Вечер перестает быть томным Если уж так хочется цепляться к словам - хотя бы цитируйте точно.

[NickS]

А что, писание на асме это "западло"?

в общем да

И это есть самый главный ответ.
Как я замечал в частных беседах об достоинствах и недостатках "С".
Больше всего отстаивают С перед ASM люди не умеющие писать на ASM.
Как я понимаю этим они просто оправдывают свою не компитентность.
Ибо любому, кто писал на ASM просмотр ASM лиснинга С компилятора приводит в ужас.

Единственное оправдание написания программ на С - доступность для понимания программистами заказчика.

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

[Виктория]

Добавление к теме о квалификации

Может быть поясните, что Вы имели в виду?

и против молодежного сленга "глючный компилятор"

Вечер перестает быть томным Если уж так хочется цепляться к словам - хотя бы цитируйте точно.

Aaarrr, давайте лучше другой пример
(а то скоро закроют тему из-за флейма)

[Andy Mozzhevilov]

Точно также, как и вашу асмовскую функцию. Только memcpy это точно все корректно отыграет, пусть даже создав менее оптимальный код, копирующий байтами, а не словами. А использование вашей функции с невыровненными адресами приведет к непредсказуемым эффектам.

А кто ее будет так использовать? Ежели это моя функция, то вызывать её буду только я и правильно.

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

Например, в IAR memcpy написана нак inline функция в string.h

Ужасно! Всегда считал IAR кривым компилером.

IAR очень приличный компилятор. Если специально не пытаться залезть в бутылочное горло, пытаясь доказать неэффективность.

Вы серьезно полагаете, что квалификация программиста тем выше, чем более низкоуровненый язык он использует?

Нет, я считаю, что квалификация программиста тем ниже, чем более низкоуровневый язык он не способен понять.

Понимать язык и уметь свободно на нем общаться - 2 большие разницы.
Вы изначально высказали мнение, что проекты для мелких микроконтроллеров должны писаться на асм:

Интересно, а на LPC2101 тоже на C будем писать?

Может быть и прекрасно, да только уж на мелких восьмибитниках ASM сам доктор прописал использовать

C чем я совершенно не согласен, настаивая на том, что целесообразно на асм писать только действительно критические места. Знание асма необходимо, это я не отрицаю, но я утверждаю, что в большинстве случаев достаточно понимать асм, а не свободно общаться на нем.
На данный момент мой опыт насчитывает работу как минимум с 7 различными семействами процессоров, не считая писишного x86. С 4 из них я работал довольно плотно. В том числе много проектов приходится сопровождать. Все написано на Ц, за исключением критических мест, которых очень не много.
Как вы считаете, насколько хорошо можно сопровождать проект, написанный на асм, если на данный момент этот процессор активно не используется?
Например, x51 мы не закладываем в новые разработки уже лет 5, а проекты сопровождать нужно. Каждый раз вспоминать асм и копаться в неструктурированном коде? Ради чего, мифического увеличения производительности и уменьшения объема кода на 30%-50%?

[AlexeyAS]

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

Что то как то все однобоко!

Си прежде всего инструмент, соответсвенно и пользоваться им можно по разному. Можно и гвозди заколачивать. Если желаете переносимиость с одной платформы на другую как можно меньшей кровью, то решение в пользу ЯВУ - однозначно.

Если переносимость не нужна и допускают сроки то можно и наверное даже нужно ассемблером побаловаться, конечно только в том случае если игра свеч стоит. Допустим сроки исполнения и ваше желание сделать проект дешевле может способствовать этому как нельзя лучше. В результате заказчик получит проект качество которого будет наивысшим и при масштабировании на большее кол-во устройств он станет еще и дешевым, ну поскольку удалось оптимизировать код под самый дешевый контроллер к примеру То что вы такой проект можете написать говорит в первую очередь о вашей квалификации, то что вы такой проект делаете реально говорит о том что вы уважаете себя и заказчика.

Если необходима оптимизация переносимого пороекта, положим для высокой скорости работы кода первым делом полезу в листинг посмотрю чего там компилер вытворяет и если вытворяет не то - поправлю его же способами из котрых pragma последний, а первый более четкое построение конструкции, разжевывание по слогам. В последнюю очередь это будет асм вставка, но если потребует скорость она будет обязательно.

Насчет повтороного - куча умных книг переписана о повтороном использовании, но понятно что повторному использованию подлежат только унифицированные части кода - а это достаточно мало (как правило какой либо алгоритм или стандартизованный вывод). Такие вещи называются еще - библиотеками. Но универсальность не всегда подразумевает удобность и как правило иногда приходится переписывать интерфейсы, что не так? Не надо манкировать повторным использованием - это не панацея.

Что в сухом остатке
1. Сравнение кода генерируемого компилятором
2. Флейм.
3. Совместное  использование асм и С.

Ну я же говорю однобоко. Можно тогда повсеместно на VM машины переходить или на FORTH процессоры, или на DSSP. Вопрос тогда сам собой отпадет последнии два выполненные на ASIC будут маш кодом автоматически являсь ЯВУ.

[AlexeyAS]

Например, x51 мы не закладываем в новые разработки уже лет 5, а проекты сопровождать нужно. Каждый раз вспоминать асм и копаться в неструктурированном коде? Ради чего, мифического увеличения производительности и  уменьшения объема кода на 30%-50%?

А что такие проекты уже не структуируются средствами АСМ и не документируются по процедурно? Сейчас такие средства появляются как графические ассемблеры - это вообще лучший выход из ситуации.

А ради чего, вопрос риторический.
Следую вашей логике можно как и в мире CPU платить огромные деньги за 30% прибавку производительности, что бы писать на ЯВУ всем и как угодно, затем еще на 10% что бы писать было быстро и каждый год по 5% что бы еще быстрее. С некоторой стороны этот принцип оправдывается получением сверхприбыли, но сущесвтует момент времени до которого потребитель согласен терепеть постоянный отъем заработанных средств .
Что говорить что подобный путь развития ЭКСТЕНСИВЕН. ;(

[VladislavS]

То же от IAR. Оценивать хорошо это или плохо не бурусь.

Это какой версией компилятора компилировалось? Какие опции оптимизации были установлены?

Последней вестимо - 4.30a. Из опций - оптимизация по скорости или по размеру дает один и тот же результат.

[Andy Mozzhevilov]

А что, писание на асме это "западло"?

в общем да

И это есть самый главный ответ.

Да.

Как я замечал в частных беседах об достоинствах и недостатках "С".
Больше всего отстаивают С перед ASM люди не умеющие писать на ASM.

Перед вами человек, умеющий писать на асм.

Как я понимаю этим они просто оправдывают свою не компитентность.

Не считаю не умение именно писать на асм в масштабе проекта - некомпетентностью. Большей некомпетентностью, я, например, считаю не умение писать под ОС. Особенно в контексте обсуждения 32битных платформ.

Ибо любому, кто писал на ASM просмотр ASM лиснинга С компилятора приводит в ужас.

Чем именно ужаснули вас те примеры, пусть мелких функций, которые я привел? Думаю, я добью со временем и fft на Ц и сравню по производительности на реальном железе, тут уже просто профессиональный интерес.

Единственное оправдание написания программ на С - доступность для понимания программистами заказчика.

Это как? Причем тут заказчик. Его как правило интересует устройство, обладающее определенными функциями и по определенной цене. О таких деталях, как компилятор, ассемблер или прочие мелочи он может даже не знать.

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

На С удобнее писать, даже если планируется лишь самоличное сопровождение.

Далее следует мое имхо:
Как я сделал вывод после продолжительного общения в конференциях есть 2 категории людей, пишуших на асм:
1 категория, это молодые люди, начинающие беспризорные embedded прогаммисты, которые выросли из железячников, закончили железячно-ориентированные ВУЗы, где упора на изучение ЯВУ не делалось. Для них очевидным выбором является ассемблер, поскольку идет он напрямую от железа, из даташитов на микроконтроллеры, а кросс-ассемблеры раздаются производителями микроконтроллеров бесплатно. Начинающим молодым специалистам не дают сложных проектов, а в небольших проектах хватает и ассемблера. По мере роста такие люди начинают заниматься более сложными проектами, где требуется писать уже относительно большие программы. Ассемблер начинает уже сдерживать, и если таких людей подтолкнуть вовремя к ЯВУ, показать, что не так страшен черт, как его молитвы, то люди делают правильные выводы, компилируют Цешный код, смотрят в листинг, видят, что не так все страшно и не оптимально, как иногда пугают. Выбирают некий баланс, между Цшным и асмовским кодом в проекте, который с опытом корректируется, как правило в сторону использования асма только в действительно оправданных и критических местах, поскольку результатом является конечное изделие, а не оптимизация на эфктивность кода в своем пределе.

2 категория, люди, считающие программирование искусством сродни живописи и сочинению музыки. Для них эффективность - это самоцель, она их волнует даже тогда, когда необходимости в ней нет. Им не важно, что программа для проекта, написанная на асме занимает 1К, а на Ц - 2K при доступной памяти 4К. Им не важно, что на асме производительность процессора используется на 50%, а на Ц- на 80%. Главное, что на асме - короче, главное, что на асме - быстрее. Как только пытаешься выянисть, в чем же причина и необходимость в этом самолюбовании, то сразу же находится куча частных случаев, в которых Ц действительно дает большой проигрыш. Цифры быстродействия и объема кода сразу становятся такими, что на асм используется 90% ПЗУ, а на Ц нужно 140%, на асм используется 80% производительности, а на Ц нужно 160%. Любимый пример - алгоритмны, использующие сдиг через перенос. Еще можно откомпилировать "hello, world!" на Ц и получить по сравнению с асм разницу в эффективности на 2 порядка. Полученные результаты начинают экстраполироваться на все, что движется. Это грустно, потому как такие люди, являясь в большинстве своем действительно профессионалами, воздействуют на неокрепшие умы категории 1, тем самым отдаляя для них перспективы перехода на ЯВУ, либо вообще переводя со временем их в свою категорию.

[Andy Mozzhevilov]

То же от IAR. Оценивать хорошо это или плохо не бурусь.

Это какой версией компилятора компилировалось? Какие опции оптимизации были установлены?

Последней вестимо - 4.30a. Из опций - оптимизация по скорости или по размеру дает один и тот же результат.

киньте проект, плз, у меня что-то несколько другой код получается.
или лист программы, которую компилируете.

[Andy Mozzhevilov]

Например, x51 мы не закладываем в новые разработки уже лет 5, а проекты сопровождать нужно. Каждый раз вспоминать асм и копаться в неструктурированном коде? Ради чего, мифического увеличения производительности и  уменьшения объема кода на 30%-50%?

А что такие проекты уже не структуируются средствами АСМ и не документируются по процедурно?

Это можно сделать, но фактически нужно будет работать компилятором с ЯВУ в уме. Это не интересно.
При большом проекте все равно придется выработать определенные правила, как то - способы передачи аргументов функциям и способы возврата результатов, соглашения по использованию регистров в вызывающей и вызываемой функциях. Для мелких архитектур, типа х51 размещение локальных переменных функций в памяти - вообще задача не тривиальная, если ее делать руками. Ну и т.п. А потом ради чего? Ради мифических 30% размера кода/производительности? Так оно и на Ц с некоторым запасом.

Сейчас такие средства появляются как графические ассемблеры - это вообще лучший выход из ситуации.

Это сейчас, а я говорю про 5 лет назад. Да и мое имхо, все эти вижал-средства для embedded больше игрушки. Попытка ввести в embedded то, что сейчас есть на ПК. Программирование контроллеров при помощи мыши. Фигня - не верю.

  А ради чего, вопрос риторический.
  Следую вашей логике можно как и в мире CPU платить огромные деньги за 30% прибавку производительности, что бы писать на ЯВУ всем и как угодно, затем еще на 10% что бы писать было быстро и каждый год по 5% что бы еще быстрее.

Вопрос очень даже практический. Если программа занимает 1К на асме, и 1.5К на Ц при доступной памяти 2К, то 0.5К оверхеда Ц бесплатно.
Только не надо мне петь про тот граничный случай, когда на асме влазит в 1 кристалл, а на Ц нужно брать более старший и платить на с50 больше. Если это даже так, то в наших, российских условиях, где преобладает мелкотиражное производтство, это мало кого волнует. Гораздо больше волнует выскочить на рынок быстрее, а там других расходов немерянно. Те же испытания на ЭМС сделать, метрологию, в коммандировки слетать по 3000р за номер/сутки - и c50 за контроллер покажутся вам каплей в морe, если до этого действительно дойдет.

С некоторой стороны этот принцип оправдывается получением сверхприбыли, но сущесвтует момент времени до которого потребитель согласен терепеть постоянный отъем заработанных средств . 
  Что говорить что подобный путь развития ЭКСТЕНСИВЕН. ;(

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

[VladislavS]

киньте проект, плз, у меня что-то несколько другой код получается.
или лист программы, которую компилируете.

Вот проект.

Прикрепленные файлы

 TEST_ARM.RAR ( 6.15 килобайт ) Кол-во скачиваний: 47

 

[dxp]

Как я замечал в частных беседах об достоинствах и недостатках "С".
Больше всего отстаивают С перед ASM люди не умеющие писать на ASM.
Как я понимаю этим они просто оправдывают свою не компитентность.

Ой, не смешите! Что там уметь? Взять документацию на проц и сразу начать писать инструкции. Тут вообще никаких знаний обширных не требуется. Именно поэтому асм так популярен среди начинающих. Все электронщинки, имеющие дело с процессорами, прошли этот путь.

А вот ЯВУ - это несколько другая песня. Тут в полный рост встают концепции языка, парадигмы программирвания, требуется знать множество нюансов, начиная от синтаксических особенностей и заканчивая привилами преобразований типов. Для того, чтобы знать С, надо прочитать не одну книжку и приобрести приличный практический опыт - я бы оценил не менее года интенсивного писания на языке. Это для С. Для С++ раза в два-три больше. В случае с асмом ничего этого не требуется.

Т.ч. перефразируя Вашу мысль - на асме голимом пишут те, кто не знает С, и заявляя, что "только асм, С - для некомпетентных", они прикрывают собственную некомпетентность.

Ибо любому, кто писал на ASM просмотр ASM лиснинга С компилятора приводит в ужас.

Это, извините, совершенно не соответствует действительности! Даже комментировать не буду такое нелепое замечание.

Единственное оправдание написания программ на С - доступность для понимания программистами заказчика.

Если человек был в состоянии освоить С, то познакомиться с мнемониками конкретного процессора для него проблемы не составит. Если "программисты заказчика" знают С, а программисты исполнителя не знают, то это означает, что программисты заказчика более квалифицированные кадры.

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

Опять мимо. Писать надо на том, что более подходит. Для проектов на МК в целом С более подходит, нежели асм. Есть отдельные случаи, если оправдано, то эти фрагменты следует выполнить на ассемблере. Но не более. Именно об этом Вам и толкуют.

Напоследок, дабы у Вас не возникало предположений о компетенции оппонентов, сообщу о своем опыте. Я, как и большинство, железячников, начинал с асма. Были времена, когда писал программы чисто на ассеблере объемом по 3 и более тысячи строк чистого кода (а для сопровождаемости там приходилось комментарии втыкать в изрядном объеме, что увеличивало и объем исходников чуть-ли не в два раза, и работы добавляло - как известно, написание качественного комментария по сложности и трудоемкости соизмеримо с объемом работы по написанию собственно кода). Было это на легендарном MCS-51. Потом появился AVR, и я пересел на него, продолжая работать в том же духе - асм, асм, для облечения жизни - макросы, бо асм у оного МК для ручного писания заметно менее приятный, чем у 51-го.

И так бы и продолжал, наверное, еще долгое время асмить, свято веря, что иного пути просто нет. Но тут увидел, как один из корешей (из другой организации) сидит и колупает IAR C (версии 1.30 еще). Я, было, поднял его на смех, типа, грю, чего ты, Мишка, дурака валяешь, кто ж для таких мелких МК на С пишет? А он отвечает, что, типа, вот заодно и узнаем, что там получается. Стали мы вместе смотреть. И вижу я, имеющий уже изрядный опыт асмования, что код (в листинге), сгенеренный компилятором, почти такой же, как я бы и сам написал. И что компилятор просто делает огромное количество тупой работы, которую без него мне приходилось делать самому. Стал тогда уже самостоятельно ковыряться, а заодно и язык учить. Мне здорово повезло - рядом оказались люди, знающие язык и наставившие сразу на пусть истинный, благодаря чему сложилось сразу правильное понимание ключевых моментов языка и правильное отношение к нему как средству для решения задач.

С тех пор акцент еще более сместился в сторону С - во-первых, компиляторы стали еще лучше оптимизировать - они стали гораздо толще и более требовательными к ресурсам, но ресуров добавилось немеренно - и памяти, и производительности процессоров, т.ч. разработчики компиляторов сосредоточились на эффектиности кодогенерации, а не на оптимизации потребления ресурсов компилятором. Во-вторых, сами МК стали толще и дешевле - взять хотя бы тот же филипковый АРМ.

Я и сегодня не брезгую ассемблером, где он действительно нужен и оправдан. Но таких случаев можно по пальцам пересчитать. Это либо ситуация, где надо задействовать конкретный аппаратные узлы процессора (относится по большей части к DSP), либо какие-то уж сильно платформеннозависимые вещи вроде переключателя контекста в RTOS. Обычный управляющий код, львиная доля которого и составляет программы для МК, прекрасно ложится на С/С++ и оверхед составляет, как уже говорили, 10-30 % (в худших случаях процентов 50). И проистекает не столько из-за плохой якобы кодогенерации, сколько из-за вещей вроде соглашений о вызове и прочих условностях, без которых никакой проект приличных размеров жить не может, безотносительно на каком языке он написан.

Что касается оппонента, которого Вы обвинили в некомпетентности, то от себя замечу, что и тут Вы оказались очень мимо кассы: этого человека я знаю давно заочно и не очень давно лично (живем в разных городах), у него очень приличный опыт работы с МК вообще и на ассемблере для них в частности. И прошел он примерно тот же типовой путь, который был описан выше. Можете не сомневаться, с квалификацией в том числе программиста на ассемблере у него все в порядке, и где надо, там пользуется. Но писать сегодня для МК - особенно такого как ARM, - ВСЕ на асме - это или мазохизм, или искусство ради искусства вроде того, как китайцы пишут на раскаленном солнцем бетоне иероглифы кисточкой, смоченной водой. Иероглифы быстро высыхают. Но там цель не написать, а писать чисто из любви к этому процессу.

[IgorKossak]

Возвращаясь к теме, вот на мой взгляд неплохой сайт для начинающих.
New Micros
Всё как по нотам расписано, но надо знать английский.
Кроме того, закачивать придётся немало.
Есть также кое-что от Macraigor Systems, тоже всё очень подробно.

[slabnoff]

2 dxp - Полностью поддерживаю!

Немного о своем опыте. Конечно, Embedded програмированием занимаюсь не особо долго, всего 8 лет, из них только 6 лет действительно серьезно и чисто программированием. Окончил я кафедру Информационных Измерительных Технологий Питерского Политеха - 50 на 50 железа и софта. Соответственно и начинал я как железячник+программист, что называется "все в одном".

Году в 1998 начал применять в своих разработках AVR-ки. На тот момент все, что было для разработки - asm от Atmel + отладчик. С учетом того, что в принципе с asm я еще 6 класса школы хорошо был знаком (первая моя программа была вообще в маш. кодах для Радио-86РК написана) и не смотря на то, что к тому моменту уже сделал пару коммерческих проектов на Си, программирование на asm'е меня не напрягало. В тот момент я еще относился к программированию как к искусству... Но все же, какое для меня было счастье получить компилятор Си! Действительно, первое время взглянув на код, генерируемый компилятором, я ужасался. Но с другой стороны, "вам шашечки или ехать?". Программировал я коммерческие изделия и от времени разработки зачастую зависела и оплата (а премии очень хотелось ), заниматься искусством от программирования позволить я себе не мог. В результате через годик уже с десяток небольших проектов были сделаны на Си. Плоды этого решения я пожинаю до сих пор: ассемблер AVR я уже плохо помню ибо больше мне не нужен, а вот поддержка старых разработок иногда возникает. Так вот поддержка ассемблерного кода зачастую вызывает ужас: ради минимальных изменений приходится иногда кардинально перелопачивать программу (в основном как раз из-за тех самых оптимизаций). В ряде случаев просто переписываю всю программу на Си. Те же программы, которые были изначально написаны на Си требуют минимальных телодвижений.

С 1999 года работаю на новом месте. Специфика работы несколько изменилась: железом занимаюсь крайне редко и только чтобы совсем не потерять квалификацию. Так вот начинал я здесь с довольно объемного проекта (порядка 50000 строк только кода, не считая таблиц, комментариев, технологического ПО, библиотек плавающей арифметики и т.п.), в котором людьми "не верящими в Си" был продавлен чистый ассемблер - я был молодой, зеленый и не мог сопротивляться мэтрам. Проект - ПО крейтовой резервированной измерительной системы, в качестве процессоров в модулях - ADSP-2185, используемые на 90% времени как быстрые микроконтроллеры. Да, конечно ассеблер у ADSP - просто сказка, но все же ОЧЕНЬ МНОГО ВРЕМЕНИ ушло на такие вещи, которые бы в случае использования Си делать бы просто не пришлось, типа всевозможных библиотек плавающей арифметики (в итоге таки презаточил/доделал под себя библиотеку Си-компилятора) - процессоры были новыми для нашей фирмы и ничего готового не было. Из-за большого объема кода такой роскоши, как серьезная оптимизация я себе просто позволить не мог - иначе был уверен, что проект потом просто умру поддерживать; все равно пришлось делать оверхеды для функций, подобные тому, что генерирует компилятор, организовывать программный стек. В итоге времени на проект было положено, на мой взгляд, слишком много. Аналогичный по объему проект на Си, правда на другой платформе, по моим оценкам был сделан за в ТРИ РАЗА меньшее время (да, конечно код там получился весьма неэффективным - на оптимизации времени не было совсем), но заказчика ведь волновали только две вещи: СРОК ИСПОЛНЕНИЯ И РАБОТОСПОСОБНОСТЬ ИЗДЕЛИЯ.

Сейчас веду проект на ARM'ах. Естественно пишу в основном на Си. Все что пришлось сделать пока на асме - переделать порт операционки под свои нужды. Надобности в ассемблерных оптимизациях пока нет. Более того, пока и оптимизации компилятора не делал. Я просто оптимизирую код сразу на Си, при этом он остается вполне читаемым, а по ассемблерному листингу - вполне эффективным. При необходимости, конечно буду использовать ассемблер...

В общем с чем я категорически не согласен, так вот с этим:

Как я замечал в частных беседах об достоинствах и недостатках "С".
Больше всего отстаивают С перед ASM люди не умеющие писать на ASM.
Как я понимаю этим они просто оправдывают свою не компитентность.

Я знаю очень классных программистов-эмбеддеров пишущих ТОЛЬКО на Си. Знаю натуральных, извините, дебилов воспевающих ассемблер (пришлось как-то такой чужой проект поддерживать - чуть с ума не сошел от того, что там было сделано, причем комментариев было один на 300 строк). По моему принципы любой разработки - "вам шашечки или ехать?"+"уважаю ли я того, кто будет поддерживать мой код"+"следует умножать сущности без необходимости".

С уважением, Андрей Слабнов.

[AlexeyAS]

А что такие проекты уже не структуируются средствами АСМ и не документируются по процедурно?

Это можно сделать, но фактически нужно будет работать компилятором с ЯВУ в уме. Это не интересно.

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

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

А что Вас stdcall не устраивает уже Если не способны отследить кроссы между регистрами и на регистровую передачу не тянете - пользуйтесь и stdcall и фреймами в процедурах. Честно говоря особой проблемы не вижу.

Для мелких архитектур, типа х51 размещение локальных переменных функций в памяти - вообще задача не тривиальная, если ее делать руками. Ну и т.п. А потом ради чего? Ради мифических 30% размера кода/производительности? Так оно и на Ц с некоторым запасом.

аргумерты оптимизации и сверхоптимизации (asm) по порядку

a) при определенной экономии кода остается место на бесполезненную модернизацию путем soft upgrade в масштабах того же устройства как понимаете.
б) при определенной экономии ресурса (производительности) опять таки остается возможность функциональной модернизации путем того же soft upgrade.
в) остается гипотетическая возможность заказного чипа на порядок дешевле но без излиществ в ASIC - это сейчас широко практикуется.

Возразить можно что а) и б) можно успеть сделать после, но вопрос что дешевле сразу или несколько погодя?

Сейчас такие средства появляются как графические ассемблеры - это вообще лучший выход из ситуации.

Это сейчас, а я говорю про 5 лет назад. Да и мое имхо, все эти вижал-средства для embedded больше игрушки. Попытка ввести в embedded то, что сейчас есть на ПК. Программирование контроллеров при помощи мыши. Фигня - не верю.

Что за ерунда!!! Какие еще визуал средства?! Какие мышевозения?! Что Вы, господь с вами! Или вот это:

r1 <- r2 + r3

считается визуал средствами визуйльной разработки? Я говорю про такие вещи как AVR AlghoritmBuilder помогающий структуировать низкоуровневый код настолько понятно и куда наглядней ЯВУ. Таже модульность только в низкоуровневом исполнении.

А ради чего, вопрос риторический.
Следую вашей логике можно как и в мире CPU платить огромные деньги за 30% прибавку производительности, что бы писать на ЯВУ всем и как угодно, затем еще на 10% что бы писать было быстро и каждый год по 5% что бы еще быстрее.

Вопрос очень даже практический. Если программа занимает 1К на асме, и 1.5К на Ц при доступной памяти 2К, то 0.5К оверхеда Ц бесплатно.

Как правило оверхед все таки выше, ведь мы рассматриваем проект а не несколько функций из него, к тому же еще и оптимизированных по асм подстрочнику. В среде embedded нет мощных оптимизирующих компиляторов допрыгивающих например до Watcom. Для того что бы достигнуть подобного уровня нужно "разжевывать" иначе компилер еще и ляпы даст, такие что выйдет дабловерхедом. Например процедура сортировки пузыркем в классическом виде будет иметь 30% оверхед и размера и производительности. Иногда компилеру просто невозможно разжевать и сдвиг то через C есть намболее качесвтенный пример

Только не надо мне петь про тот граничный случай, когда на асме влазит в 1 кристалл, а на Ц нужно брать более старший и платить на с50 больше. Если это даже так, то в наших, российских условиях, где преобладает мелкотиражное производтство, это мало кого волнует.

А я Вам и не пою про размеры кристаллов, как Вы уже могли заметить, я назвал причины а),б),в) должные побудить писать на средствах низкого уровня (заметье я не говорю именно ассемблер). Только попробуйте скажите что средства низкого уровня не позволяют структуировать и заставляют делать дурную работу

Гораздо больше волнует выскочить на рынок быстрее, а там других расходов немерянно. Те же испытания на ЭМС сделать, метрологию, в коммандировки слетать по 3000р за номер/сутки - и c50 за контроллер покажутся вам каплей в морe, если до этого действительно дойдет.

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

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

Насчет "вылизать" я не буду верить в это с самого начала коммерческого проекта. Самое интересное то что так говорят абсолютно все! В итоге, проект бросается и заказчику говорят, да бросьте вы свой пылесосо, КПК или телефон (к примеру) мы выпустили новый, а старый там же нет того и того, а оно вам так надо! Не ощущаете схожесть ситуаций?!

[Andy Mozzhevilov]

Это можно сделать, но фактически нужно будет работать компилятором с ЯВУ в уме. Это не интересно.

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

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

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

А что Вас stdcall не устраивает уже Если не способны отследить кроссы между регистрами и на регистровую передачу не тянете - пользуйтесь и stdcall и фреймами в процедурах. Честно говоря особой проблемы не вижу.

Так пользуйтесь, я же не агитирую. Я лишь не вижу смысла прописывать ручками то, что может сделать вычислительная машина.

Для мелких архитектур, типа х51 размещение локальных переменных функций в памяти - вообще задача не тривиальная, если ее делать руками. Ну и т.п. А потом ради чего? Ради мифических 30% размера кода/производительности? Так оно и на Ц с некоторым запасом.

аргумерты оптимизации и сверхоптимизации (asm) по порядку

a) при определенной экономии кода остается место на бесполезненную модернизацию путем soft upgrade в масштабах того же устройства как понимаете.
б) при определенной экономии ресурса (производительности) опять таки остается возможность функциональной модернизации путем того же soft upgrade.
в) остается гипотетическая возможность заказного чипа на порядок дешевле но без излиществ в ASIC - это сейчас широко практикуется.
Возразить можно что а) и б) можно успеть сделать после, но вопрос что дешевле сразу или несколько погодя?

Заказной чип на порядок дешевле - не смешите. Сейчас контроллер ARM стоит от $2, куда дешевле? Знаете сколько стоит подготовка производства заказных чипов? Знаете, при каких тиражах это все начинает окупаться? Сколько раз в своей практике вы делали заказ заказных чипов?

Что за ерунда!!! Какие еще визуал средства?! Какие мышевозения?! Что Вы, господь с вами! Или вот это:

r1 <- r2 + r3

Как это выражение относится к словосочетанию графический ассемблер?
Наличием стрелочки в пересылке? Что такое здесь r1 r2 и r3, какие сущности они выражают? В чем кайф?

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

Да ну вас.

классическом виде будет иметь 30% оверхед и размера и производительности. Иногда компилеру просто невозможно разжевать и сдвиг то через C есть намболее качесвтенный пример

Как я и писал выше, любимый пример, сдвиг через перенос.

Насчет "вылизать" я не буду верить в это с самого начала коммерческого проекта. Самое интересное то что так говорят абсолютно все! В итоге, проект бросается и заказчику говорят, да бросьте вы свой пылесосо, КПК или телефон (к примеру) мы выпустили новый, а старый там же нет того и того, а оно вам так надо! Не ощущаете схожесть ситуаций?!

нет, не ощущаю, устал от непробиваемости, больше на разводы руками и вопросы из теории вероятности в стиле "а вот бывает" отвечать не намерян. Жду стандартного в этих случаях "оппонент слил, слив защитан".

PS: Впрочем, предлагаю пари любому ассемблерщику. Формулируем ТЗ на какой-нибудь проект средней сложности, в который не закладывается необходимотсь знаний в специфических областях и который может быть реализован в пределах простой evalboard на uC с периферией типа UART, светодиоды, кнопки и т.п., то есть в конфигурации, которую может сделать быстро любой. Я выполняю требования ТЗ на Ц, кто-либо на асм. Результаты сравниваем. Я утверждаю, что оверхед по объему быстродействию будет в пределах 30-50%, и скорее менее, чем более. Делать буду на LPC213x

[AlexeyAS]

Году в 1998 начал применять в своих разработках AVR-ки. На тот момент все, что было для разработки - asm от Atmel + отладчик. С учетом того, что в принципе с asm я еще 6 класса школы хорошо был знаком (первая моя программа была вообще в маш. кодах для Радио-86РК написана)

Как все однако похоже Найти бы тех людей которые монитор писали для РК и попросить бы их его на Си переделать, посмотрел бы я на нас тогда в то время как бы мы прыгали в поисках ПЗУ чуть больше стандартных 2К. Или его писали на Си )

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

Вот заметьте все сводится к заурядному "время - деньги" не более!
И еще в таких коллективах !наверное! не желают тратить время на изучение других средств и технологий проектирования, а любителям в этом случае проще у них есть время и желание и возможность искать другие средства. Для 0x86 например давно уже существует c--, для AVR как я и говорил граф. ассемблер и отзывы только положительные. Сам приеняю Си только тогда когда в AVR Buider не хватает лимита по коду (у меня Демо). Было бы подобное под ARM пользовался бы не задумываясь.

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

Это случай перехода с платформы на платформу?

вещи: СРОК ИСПОЛНЕНИЯ И РАБОТОСПОСОБНОСТЬ ИЗДЕЛИЯ.

Ну все сказано этими строками абсолютно все.

[AlexeyAS]

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

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

э...э.... Нет ну Вы, извините, даете. Знаете я тоже люблю Си, очень люблю С++, но отрицать очевидное....... Его препроцессор те же макросы. Далеко вы уедите без препроцессора на Си? при компиляции ключ -E поставте.

По поводу макросов на ассемблере я же говорю есть разные реализации и реинкарнации препроцессора для ассемблера, может вы не все видели?

А что Вас stdcall не устраивает уже Если не способны отследить кроссы между регистрами и на регистровую передачу не тянете - пользуйтесь и stdcall и фреймами в процедурах. Честно говоря особой проблемы не вижу.

Так пользуйтесь, я же не агитирую. Я лишь не вижу смысла прописывать ручками то, что может сделать вычислительная машина.

Не понимаю, только что говорили о макросах и stdcall завернуть в макрос это не долго.
Собственно я о чем толкую я видел на wasm.ru как пользуются успешно очень успешно примитивным стандартным препроцессором, честно скажу так как я умею им пользоваться мне завидно, поэтому то что я пишу на Си, они пишут на ассемблере не напрягаясь. Нужно уметь пользоваться инструментом - это факт.

аргумерты оптимизации и сверхоптимизации (asm) по порядку

a) при определенной экономии кода остается место на бесполезненную модернизацию путем soft upgrade в масштабах того же устройства как понимаете.
б) при определенной экономии ресурса (производительности) опять таки остается возможность функциональной модернизации путем того же soft upgrade.
в) остается гипотетическая возможность заказного чипа на порядок дешевле но без излиществ в ASIC - это сейчас широко практикуется.
Возразить можно что а) и б) можно успеть сделать после, но вопрос что дешевле сразу или несколько погодя?

Заказной чип на порядок дешевле - не смешите. Сейчас контроллер ARM стоит от $2, куда дешевле?

Ну-ну. Вы все таки норовите не дочитать

в) остается гипотетическая возможность заказного чипа

Знаете сколько стоит подготовка производства заказных чипов? Знаете, при каких тиражах это все начинает окупаться?

Знаю.

Сколько раз в своей практике вы делали заказ заказных чипов?

Ноль.

Значит будем считать что с а) и б) Вы согласны

Что за ерунда!!! Какие еще визуал средства?! Какие мышевозения?! Что Вы, господь с вами! Или вот это:

r1 <- r2 + r3

Как это выражение относится к словосочетанию графический ассемблер?

да очень просто http://home.tula.net/algrom/russian.html

Ему такое название дали потому что он не текстовое а графическое средство.

Кстати существуют такие же средства для Си, думаете излишество?

Наличием стрелочки в пересылке? Что такое здесь r1 r2 и r3, какие сущности они выражают? В чем кайф?

ну хорошо не нравятся регистры там и подругому можно, так лучше

family <- roma + masha

Теперь хотя бы очевидны сушности

Вы попоробуйте - кайф он сам приходит во время работы и от хорошо сделанной работы

классическом виде будет иметь 30% оверхед и размера и производительности. Иногда компилеру просто невозможно разжевать и сдвиг то через C есть намболее качесвтенный пример

Как я и писал выше, любимый пример, сдвиг через перенос.

Т.е. я так понимаю в МК это излишество да? Пользоваться им не нужно и реализация этого в кристалле бесплатный довесок?

Ну вот вам из x86 - bswap, да и вообще любые свапы, что замечено разработчиками c-- и очень простенько пределано в синтаксис Си:

i >< j

Насчет "вылизать" я не буду верить в это с самого начала коммерческого проекта. Самое интересное то что так говорят абсолютно все! В итоге, проект бросается и заказчику говорят, да бросьте вы свой пылесосо, КПК или телефон (к примеру) мы выпустили новый, а старый там же нет того и того, а оно вам так надо! Не ощущаете схожесть ситуаций?!

нет, не ощущаю, устал от непробиваемости, больше на разводы руками и вопросы из теории вероятности в стиле "а вот бывает" отвечать не намерян. Жду стандартного в этих случаях "оппонент слил, слив защитан".

Собственно не ожидал ничего другого.

PS: Впрочем, предлагаю пари любому ассемблерщику.

Я не ассемблерщик. Я тот кто в чем то защищает опонентов ратающих за полное использование ресурсов.

Формулируем ТЗ на какой-нибудь проект средней сложности, в который не закладывается необходимотсь знаний в специфических областях и который может быть реализован в пределах простой evalboard на uC с периферией типа UART, светодиоды, кнопки и т.п., то есть в конфигурации, которую может сделать быстро любой. Я выполняю требования ТЗ на Ц, кто-либо на асм. Результаты сравниваем. Я утверждаю, что оверхед по объему быстродействию будет в пределах 30-50%, и скорее менее, чем более. Делать буду на LPC213x

Я с цифрами 30-50% соглашусь заранее зачем терять время. Только не пойму что это доказывает. В рамках светодиодов спорить не очем, а от более крупного проекта вроде ОС+сотовый телефона - при том же процентном оверхеде, абсолютные цифры будут другие и они как раз таки скажутся на его цене. Или несогласны.

[Andy Mozzhevilov]

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

э...э.... Нет ну Вы, извините, даете. Знаете я тоже люблю Си, очень люблю С++, но отрицать очевидное....... Его препроцессор те же макросы. Далеко вы уедите без препроцессора на Си? при компиляции ключ -E поставте.

И в Ц макросы - зло, если их использовать вместо функций. Я думаю о чем тут речь, понятно, если вы действительно хорошо владеете Ц.

нет, не ощущаю, устал от непробиваемости, больше на разводы руками и вопросы из теории вероятности в стиле "а вот бывает" отвечать не намерян. Жду стандартного в этих случаях "оппонент слил, слив защитан".

Собственно не ожидал ничего другого.

жаль, что вы именно так думаете

PS: Впрочем, предлагаю пари любому ассемблерщику.

Я не ассемблерщик. Я тот кто в чем то защищает опонентов ратающих за полное использование ресурсов.

Я правильно понял, что если в проекте не была использована ни разу, скажем команда сдвига через перенос, то ресурсы считаются не использованными на 100% и это вас напрягает?

Я с цифрами 30-50% соглашусь заранее зачем терять время. Только не пойму что это доказывает. В рамках светодиодов спорить не очем, а от более крупного проекта вроде ОС+сотовый телефона - при том же процентном оверхеде, абсолютные цифры будут другие и они как раз таки скажутся на его цене. Или несогласны.

Считаю, что проекты под вытесняющей ОС начинают требовать меньше вычислительных ресурсов процессора при проходе некоторой критической точки сложности проекта.

[Виктория]

То AlexeyAS

Ну уж про Algoritm Bilder - это совсем зря. Тоже мне графический язык (мыслить на уровне блок-схем - это тот же ассемблер).

Если нужен пример другого подхода графического программирования - то обратите взор на стандарт IEC 61131-3. Вот это профессиональный подход (правда только для предметной области АСУТП). Чтобы избежать дальнейших провокаций - да здесь еще менее оптимально, чем на Си. Но зато какая технология!

А уж про Algoritm Bilder, это уж Вы совсем зря... Ничего эта среда не дает. Кроме того, что это все на заре появилось (не было IAR и т.п.)

З.Ы: Замечено при чтении сегодняшней бурной дискуссии, что сторонники ассемблера избегают описания своего жизненного (проектного) пути

[Andy Mozzhevilov]

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

С учетом того, что в принципе с asm я еще 6 класса школы хорошо был знаком (первая моя программа была вообще в маш. кодах для Радио-86РК написана)

Как все однако похоже Найти бы тех людей которые монитор писали для РК и попросить бы их его на Си переделать, посмотрел бы я на нас тогда в то время как бы мы прыгали в поисках ПЗУ чуть больше стандартных 2К. Или его писали на Си )

Вам пытаются показать, что опыт конкретных людей не с пустого места вырос, и что конкртеные люди прошли в том числе через коды, асм и прочие прелести. Ваши же смайлики и передергивания здесь выглядят как минимум издевкой.
Да, я тоже писал в кодах совсем давно. Писал для Zx на бумаге, потом по таблицам переводил в коды и через оператор DATA интерпретатора бейсик заносил в память и там запускал. Писал очень давно на Atati - были такие мелкие компы на 6502, тоже на ассемблере с ручным переводов в коды.
Это плохо?

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

Вот заметьте все сводится к заурядному "время - деньги" не более!

В том или ином виде - да. Но если бы я писал сейчас ради хобби, это был бы Ц.

И еще в таких коллективах !наверное! не желают тратить время на изучение других средств и технологий проектирования, а любителям в этом случае проще у них есть время и желание и возможность искать другие средства.
Для 0x86 например давно уже существует c--, для AVR как я и говорил граф. ассемблер и отзывы только положительные. Сам приеняю Си только тогда когда в AVR Buider не хватает лимита по коду (у меня Демо). Было бы подобное под ARM пользовался бы не задумываясь.

Это разрозненные технологии, "театр одного актера", инструмент одного процессора. Положительная сторона Ц в том, что существует стандарт на язык, в рамках которого реализованы компиляторы с него. При смене платформы необходимо лишь изучить расширения языка, связанные с особенносями архитектуры конкретного ядра.
А технологии, которые действительно помогают качественно разрабатывать и сопровождать проекты изучать надо. Могу посоветовать изучать RTOS - как технологию программирования, и CVS/SVN - как средство сопровождения проектов (независимо от того, на чем они написаны).

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

Это случай перехода с платформы на платформу?

У меня есть обширный и положительный опыт повторного использования исходников в различных проектах и для различных платформ. Есть опыт ведения одного проекта сразу на 2 платформах, скажем последний - Fujitsu MB90 и ARM.

вещи: СРОК ИСПОЛНЕНИЯ И РАБОТОСПОСОБНОСТЬ ИЗДЕЛИЯ.

Ну все сказано этими строками абсолютно все.

тогда озвучьте ваш поинт, ваше мнение, на чем вы стоите? что пытаетесь доказать?

[AlexeyAS]

И в Ц макросы - зло, если их использовать вместо функций.

Абсолютное? Что же за категоричность то такая?!
Вы вообще то, хидеры то включаете в проекты? А я то считал что использование макросов как функций облегчает порт своего кода на чужую платформу, или вы считаете что делать тайпкастинг параметров нужно каждый раз при вызове, ну просто потому что макрос-функция абсолютное зло и религия его не позволяет использовать? А совершенно детский пример реализации Max(A, и Min(A, через макрос, зряшен, будем везде писать его чистую реализацию?! Бедный Ричи! Тогда чего уж по инкапсуляции не пройтись в C++, она тоже некоторые моменты реализации скрывает, не будем использовать?

Я думаю о чем тут речь, понятно, если вы действительно хорошо владеете Ц.

Да бросьте Вы такие вещи, я не зеленый пацан что бы меня разводить на подобном )!
Я очень посредственно владею Си и гораздо хуже чем Си владею С++. Мне не стыдно придерживаться принципа «Чем шире круг познания, тем огромней граница с незнанием».

Я не ассемблерщик. Я тот кто в чем то защищает опонентов ратающих за полное использование ресурсов.

Я правильно понял, что если в проекте не была использована ни разу, скажем команда сдвига через перенос, то ресурсы считаются не использованными на 100% и это вас напрягает?

Вы знаете почему то нет, «нет» в смысле не правильно Вы меня поняли. Видимо Ваша предубежденность таки сказывается. Меня напрягает то что существует «эффективное» и «не эффективное» использование. А Вы вместо того что бы согласится, что мол да «не эффективно» мы используем ресурсы кристалла и нет в наших поделках особого изыска и красоты, воздвигаете такую ситуацию в ранг сверхнормальных «так должно быть!».
Если бы так должно быть и Си недолжна практически никогда использовать сдвиг через С (и еще кучу чего), то почему бы производителю чипов не согласится с Вами и не выпустить партию с еще более урезанной системой команд? Видимо осознает производитель что подобная способность кристалла будет востребована.
Вы же все время упираете на то что нет «кроме Си бога на земле и С++ пророк его», что с моей точки зрения совершенно необоснованно. Я вам привел пример развития как парадигмы Си (C--) так и парадигмы Асм (граф.ассемблер). Не станете же Вы отрицать что они используют ресурсы платформы в разы полнее, нет?

Я с цифрами 30-50% соглашусь заранее зачем терять время. Только не пойму что это доказывает. В рамках светодиодов спорить не очем, а от более крупного проекта вроде ОС+сотовый телефона - при том же процентном оверхеде, абсолютные цифры будут другие и они как раз таки скажутся на его цене. Или несогласны.

Считаю, что проекты под вытесняющей ОС начинают требовать меньше вычислительных ресурсов процессора при проходе некоторой критической точки сложности проекта.

Тьфу ты нуты…. Так оверхед то свое возьмет, плюс еще кретинизм не самых худших в мире разработчиков (например Samsung) и как пить дать придется и Вам и мне как потребителям на 1,5 тыс. лишнего переплачивать за бедную функциональность при весьма богатых возможностями потрохах. И через год дорабатывать его firmware будут пара тройка хакеров, так как о «на Си сгенерированном коде внутри» забудет даже сам самсунг.

[AlexeyAS]

То AlexeyAS

Ну уж про Algoritm Bilder - это совсем зря. Тоже мне графический язык (мыслить на уровне блок-схем - это тот же ассемблер).

Да что Вы говорите? Вот уж не думал что наше государство думало жопой когда ГОСТы по оформлению алгоритмов принимала. Вам выслать парочку, прочтение очень между прочим дисциплинирует. Так дальше пойдет, скоро скажем да что там алгоритм и алгоритмические конструкции – разве де мыслить так возможно Погорячились что то Вы с ремаркой.

Если нужен пример другого подхода графического программирования - то обратите взор на стандарт IEC 61131-3. Вот это профессиональный подход (правда только для предметной области АСУТП). Чтобы избежать дальнейших провокаций - да здесь еще менее оптимально, чем на Си. Но зато какая технология!

Зачем поднимать тему в этом случае, я же говорю подобные вещи существую и под С++. Но Algorithm Builder уникален именно тем что не создает подобных оверхедов при этом оставаясь интуитивно понятным в противовес ассемблеру.

А уж про Algoritm Bilder, это уж Вы совсем зря... Ничего эта среда не дает. Кроме того, что это все на заре появилось (не было IAR и т.п.) .

Был IAR и был GNU и был CodeVision, это Вы зря.

З.Ы: Замечено при чтении сегодняшней бурной дискуссии, что сторонники ассемблера избегают описания своего жизненного (проектного) пути

Я уже отвечал что я не сторонник Асм, но и Си не оправдываю за его «косность» в абсолютном большинстве случаев.


Что касается жизненного пути, я не хотел отвечать на этот вопрос, но пост ниже наполнен каким то негативом и агресией в мою сторону, хотя смайлы я ставлю именно для того что бы обсуждение не перетекло в закидывание банановой кожурой. Только что толку медалями бряцать, поверьте мне есть чем гордится. Ну так же с РК86 и ассемблера 8080 начинал по галимой бумажки писать программы без еще самого РК, но только в 8 классе, так как в мое время в 6 классе мне не так свезло и были только «Наука и Жизнь» + «ТМ» в которых описывался МК-61, БЗ-34. Их то с трудом можно считать за компьютер (у меня был МК-61), ах да в то время мне удалось познакомится еще с калькулятором от TI, с магнитными карточками для считывания и скоростью выполнения всей программы, как у МК-61 один шаг То что я писал под них – куда эффективней чем то что сейчас на Си, так как вся программа была алгоритмически выверена на десятки раз с помощью тех самых присловутых блок схем (это не долго поверьте мне, зато мысли дисциплиниурет). А еще помню на 59 (или нет?) АЦП стоял но не успел замучить (делал расчет титрования для химиков). До мозолей в пальцах (от набивок дампов из Радио) знаком с РК86 (то что печатали в ЮТ решил не делать, так как "печатку" от РК нашел вперед), Орион (эх его бы на два года раньше опубликовать), Z80 во всех реинкарнациях от сэра Клайва как и все в то время (именно с Z80 начал осваивать Си и Паскаль) , ДВК и PDP в институте, ИСКРА на кафедре и «Поиск» в личном владении (ох и Г.) мои первые x86. Пневмо-автоматика и карты Карно для оптимизации- защита диплома на кафедре это первый «макроконтроллер» . Начиная с этого момента все конструкции только для себя PIC, затем AVR, ну про x86 молчу. Теперь наконец получил из аргусса AT91SAM7S64.
Все проекты только для себя и собственной конторы как уже и говорил. Да я сроками не ограничен, потому могу позволить себе эксперименты с оптимизацией и поиском других инструментов. Жалко того кто себе такого позволить не может. По ЯВУ (Паскаль, Модула, Оберон, FORTH, DSSP [была даже реализованная попытка DSSP на AVR, но быстро понял что DSSP будет блистать только обрамленным в ПЛИС]) перебрав почти все и пописал на всем этом для x86, настолько долго что чуть не позабыл ассемблер, остановился на C++. Умнее Watcom компиляторов не видел, тем что вытворяет он под x86 не один другой похвастаться не может, жалко что его нет под ARM. А под ARM не один компилер не может похвастаться большим чем любой оптимизирующий под x86, хочу посмотреть на Metrowerks под ARM может он «могет»(работал с ним под BeOS), но до «своих» не дорос .