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

[=NIK=]

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

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

[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 кривым компилером.

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

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

[Andy Mozzhevilov]

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

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

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

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

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

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

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

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

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

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

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

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

[AlexeyAS]

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

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

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

[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, если до этого действительно дойдет.

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

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

[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]

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

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

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

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

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

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

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

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

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

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

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

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

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