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

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

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