[AlexandrY 2]

6 hours ago, xvr said:

Нужно ли всегда просматривать листинги после компилятора?

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

6 hours ago, xvr said:

Нужно ли знать ассемблер обычному разработчику?

Знать не надо.
Это дело 10 секунд узнать все что надо об ассемблере, когда понадобится. Знать надо периферию.  
Для справки, детальное описание ассемблера - 394 страницы, неполное описание периферии несильно навороченного МК перевалит за 3000 страниц.  

6 hours ago, xvr said:

Можно ли писать программы на МК не зная его архитектуру?

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

6 hours ago, xvr said:

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

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

[haker_fox 60]

8 hours ago, AHTOXA said:

Но прям "нужно смотреть" (видимо, после каждой компиляции?) - зачем?

Ответ "нужно смотреть" был адресован уважаемому @xvr, чтобы подчеркнуть тематику темы. Естественно, что после каждой компиляции туда заглядывать нет смысла. Тем не менее, периодически заглядывая в ассемблерные листинги, иногда можно обнаружить что-то такое, что не видно в исходном тексте. Возможно это имеет смысл делать для критических мест. Например, не далее, чем вчера, подчищал в одном проекте обработчик прерывания, который вызывается с периодом 50 мкс, делает кучу работы. Архитектура Cortex-M4F. Не могу сказать, что были какие-то тормоза, просто интереса ради. И обнаружил, что в перывании так негусто, но всё же, вызывается аллокатор кучи. Вернулся к исходникам на Си++, и обнаружил, что в синглтоне для создания объекта применяется куча. Переделал синглтон. Код, не могу привести, я сейчас на на работе. Я понимаю, что это можно было сделать и не заглядывая в листинг, но мне помог именно он. Также поотлавливал несколько операций с float и dobule. Понятно, что для кортексовского FPU это семечки, но в случае с double уже вызывается встроенная библиотека, что ни есть хорошо. Да и double там не нужен. В итоге все расчёты, которые можно было вытянуть из прерывания я унёс в основной код. Да, и снова это можно было найти, просматривая сишный код. Но, в принципе, это справедливо в большинстве случаев. Но листинг, ИМХО, это как фильтр. Если ожидаешь, что процессор должен сложить два числа, а на ассемблере видищь, что вызывается ещё какая-нибудь халабуда, то вот оно - место для оптимизации и исправления ошибок. Ещё раз, всё это моё ИМХО. И да, немало проблем в исходном тексте находят статические анализаторы. Знаю, использую)

 

[AlexandrY 2]

7 hours ago, haker_fox said:

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

Не забывайте также про реверс, уязвимости и Interrupt-oriented Bugdoor Programming
Современные дивайсы с IoT  от тех кто не смотрит машинный код, просто находка для взломщиков всех мастей. 
Просто песня когда примитивные сканеры дампов находят строки, стандартные алгоритмы, целые стандартные стеки в сорсах ( типа FreeRTOS или чён-нить из STL  С++ с исключениями) 

[Forger 17]

Производители МК тоже не стоят на месте и пилят новые семейства уже по подобные особенности IoT, например: https://www.st.com/content/st_com/en/about/media-center/press-item.html/p4087.html

[AlexandrY 2]

5 hours ago, Forger said:

Производители МК тоже не стоят на месте и пилят новые семейства уже по подобные особенности IoT, например: https://www.st.com/content/st_com/en/about/media-center/press-item.html/p4087.html

Эт не избавит от необходимости посматривать дампы кода. 
А вот у NXP уже есть встроенный PUF,  и это реально меняет дело. 

[jcxz 184]

В 07.02.2020 в 18:51, xvr сказал:

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

• Сразу - нет. Если код выполняется за заданное время и потребляет заданный объём FLASH и RAM, то какая разница как он там внутри устроен?

Это не всегда так. Например:

Есть некая функция, выполняющая определённую задачу. Функция тяжёлая, скажем занимает 20% ресурса быстродействия CPU. Написана на си, быстродействия в целом на весь проект пока хватает и есть ещё большой запас. Но к моменту написания этой функции проект ещё в стадии разработки и конца её не просматривается на горизонте. Функция хоть и тяжёлая, но по алгоритму - простая, легко переписать на ассемблер, и при этом она ускоряется в 2 раза.

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

В 07.02.2020 в 01:08, Rst7 сказал:

А так intrinsic'и вполне решают задачу. Щас продемонстрирую.

Так ведь они (intrinsic'и) - это уже собственно ассемблер. Завуалированный. А значит - раз вы их применяете - значит знаете и используете ассемблер.  

В 07.02.2020 в 17:31, xvr сказал:

В исходном коде - 128 (если не учитывать первый пункт из этого ответа). А это ещё более дофига - в 4 раза

Видимо Вы имеете в виду код типа?:

  if (bm & 1ull << 0) { *(__packed u32 *)p = var0; p += 4; }
  if (bm & 1ull << 1) { *(__packed u16 *)p = var1; p += 2; }
  if (bm & 1ull << 2) { *(__packed u32 *)p = var2; p += 4; }
  if (bm & 1ull << 3) { *(__packed u32 *)p = var3; p += 4; }
  if (bm & 1ull << 4) { *(__packed u16 *)p = var4; p += 2; }

Так там не будет ни одного перехода (при компиляции оптимизирующим компилятором). Так как в ARM есть условное выполнение команд.

[Rst7 5]

7 minutes ago, jcxz said:

Так ведь они (intrinsic'и) - это уже собственно ассемблер. Завуалированный.

Ну все-таки не совсем. Если бы я делал asm("UQSUB16 %0,%0,%1":"+r"(max):"r"(*_s++)); - вот тогда да, ассемблер. А так пока никакого выхода за границу разумного для чистого ЯВУшника - ну подумаешь, есть функция __uqsub16(), которая хитро вычитает половинки long'ов.

Приведу пример с большого брата (да, Intel'у отдельный котел в аду черти растопили за то, что в SIMD-инструкциях нет знакового сложения с сатурацией для пачки 32хбитных операндов, приходится вот такое изобретать):

static inline __m128i selectb(__m128i s, __m128i a, __m128i b) {
#if 1   // SSE4.1 supported
	return _mm_blendv_epi8(b, a, s);
#else
	return _mm_or_si128(
		_mm_and_si128(s, a),
		_mm_andnot_si128(s, b));
#endif
}

static inline __m128i add_saturated(__m128i a, __m128i b) {
	__m128i sum = _mm_add_epi32(a, b);                  // a + b
	__m128i axb = _mm_xor_si128(a, b);                  // check if a and b have different sign
	__m128i axs = _mm_xor_si128(a, sum);                // check if a and sum have different sign
	__m128i overf1 = _mm_andnot_si128(axb, axs);            // check if sum has wrong sign
	__m128i overf2 = _mm_srai_epi32(overf1, 31);            // -1 if overflow
	__m128i asign = _mm_srli_epi32(a, 31);                 // 1  if a < 0
	__m128i sat1 = _mm_srli_epi32(overf2, 1);             // 7FFFFFFF if overflow
	__m128i sat2 = _mm_add_epi32(sat1, asign);            // 7FFFFFFF if positive overflow 80000000 if negative overflow
	return  selectb(overf2, sat2, sum);                      // sum if not overflow, else sat2
}

Это asm или не asm?

[xvr 12]

On 2/9/2020 at 12:23 PM, jcxz said:

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

Зачем? Времени CPU на всё (включая эту функцию) хватает с избытком. Если вы её ускорите в 2 раза, процессору придётся меньше времени работать и больше простаивать, т.к. общее количество работы осталось пржним. FLASH'а тоже хватало, уменьшение объёма кода ни к чему не приведёт. Сэкономленные такты и байты вы не на что обменять не сможете, это в чистом виде потерянный капитал - вся экономия останется мёртвым грузом внутри.

Единственно, что вы точно потеряете - это своё собственное время, потраченное на переписывание.

On 2/9/2020 at 12:23 PM, jcxz said:

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

Задокументируйте это место и всё, что вы хотели тут сделать, и делаёте когда реально понадобится (если вообще понадобится).

On 2/9/2020 at 12:23 PM, jcxz said:

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

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

On 2/9/2020 at 12:23 PM, jcxz said:

Так там не будет ни одного перехода (при компиляции оптимизирующим компилятором). Так как в ARM есть условное выполнение команд.

И в thumb режиме тоже? Тогда пардон, предложение своё снимаю, и предлагаю оставить всё как было (на С)

On 2/8/2020 at 5:26 AM, haker_fox said:

Возможно это имеет смысл делать для критических мест.

Абсолютно точно, и только для них.

 

К сожалению это не всегда возможно Я сейчас пишу небольшую программу на 8052 на SDCC. В код стараюсь не смотреть - у меня сразу становятся волосы дыбом и возникает огромное желание переписать всё на корню Несколько мест перписал (они  реально тормозили - было видно невооружённым глазом), от остального сдерживаюсь (с трудом). Так же с трудом сдерживаюсь от желания допилить сам компилятор (SDCC) - текущая задача разовая, и пока других тасков с 8051/2 не предвидится.

Пробовал Keil, код получше, но всё равно далёк от идеала. Других компиляторов (свободно доступных) не нашёл

[jcxz 184]

3 часа назад, xvr сказал:

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

Почему "не разобраться-то"??? Вопрос во времени, которое нужно потратить на это самое "разобраться". Потом, через год, сколько не пиши документации, если алгоритм сложный - времени потребуется много чтобы всё вспомнить и разобраться. И чем больше документации - тем больше времени читать и вспоминать. Если я знаю, что потом мне чтобы вспомнить, потребуется как минимум неделя, в то время как сейчас, по горячим следам на то чтобы написать оптимальнее, нужна пара часов, и я вполне допускаю что в дальнейшем это потребуется, то я сейчас и напишу на ассемблере. Сразу. Хотя сейчас производительности CPU и хватает. Потому что - одно дело документация, которую надо ещё прочитать и найти все нужные места которые нужно прочитать и другое дело - когда весь алгоритм в голове. По горячим следам.

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

 

То же касается не только быстродействия, но и ОЗУ - всегда стараюсь писать оптимально, с минимальным расходом ОЗУ. Даже если кажется, что его вагон и на всё хватит. Потому что никогда не знаешь - куда пойдёт проект дальше и что ещё понадобится через несколько месяцев заказчику. Потому что лучше сейчас потратить 1 час, сразу написав оптимально, чем потом - месяц, на переписывание всего. Здесь конечно уже не об ассемблере разговор, но принцип тот же самый.

 

Цитата

И в thumb режиме тоже? Тогда пардон, предложение своё снимаю, и предлагаю оставить всё как было (на С)

И в нём тоже.

[SVNKz 1]

9 часов назад, jcxz сказал:

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

Всегда предупреждаю заказчика о невозможности полного соответствия работы программы заданным в ТЗ условиям. Почти всегда сам работодатель незнаком со всеми необходимыми ему функциями программы, которые выявляются в процессе опытной эксплуатации программы. Поэтому в ТЗ закладываются "Этапы разработки" с указанием объёмов и сроков доработки программы в соответствии с дополнительными требованиями заказчика, на которые тоже разрабатывается дополнительное ТЗ. Иной вариант разработки программы автоматически обеспечивает риски заработать репутацию недобросовестного исполнителя. 

[makc 192]

Admin: оффтопик и флейм скрыты. Их продолжение неизбежно повлечет за собой предупреждения и закрытие темы.

Не превращайте раздел для начинающих в филиал раздела "Общение".

[xvr 12]

19 hours ago, jcxz said:

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

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

19 hours ago, jcxz said:

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

Караул, как же вы вообще разрабатываете?

19 hours ago, jcxz said:

И если Вы этого не понимаете, то видимо Вы не умеете планировать свою работу, и выделять приоритетные направления и задачи.

Понимаю, поэтому и не бросаюсь сразу всё оптимизировать. Ибо это совсем не приоритетная задача.

19 hours ago, jcxz said:

И стараться решать задачи с минимальными времязатратами.

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

Ознакомьтесь что ли с современными методиками разработки, с тем же agile (и не надо утверждать, что он не подходит для embedded - он везде подходит, с небольшими адаптациями)

Если не нравится agile - возьмите другие модели (итерационная модель, спиральная). Ни в одной из них нет 'вылизывания всех блох на месте'. Везде развитие итерационное. (Модель водопада не рассматриваем - для неё нужно полное и конечное ТЗ прямо при старте).

А вы тут пытаетесь изобрести свою методологию разработки (сомнительную) и выдать её за непререкаемый всемирный стандарт.

19 hours ago, jcxz said:

другое дело - когда весь алгоритм в голове.

Он не должен быть в голове - он должен быть на бумаге (в виде документации)

[xvr 12]

Кажется я понял, откуда у нас с уважаемым jcxz такое расхождение во взглядах на немедленное переписывание узких мест на ассемблере.

 

Есть 2 диаметрально разных способа (или окружения) для програмирования для МК (и не только для МК).

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

1й подход характерен для хоби и/или фриланса. Если вы смогли за это ещё и большие деньги получить - вам сказочно повезло

2й подход - для индустрии (и да, вам за это будут платить зарплату  )

Переход от 1го ко 2му координально рвёт все шаблоны и вгоняет в когнитивный диссонанс (по себе знаю)

[Forger 17]

11 minutes ago, xvr said:

1й подход характерен для хоби и/или фриланса. Если вы смогли за это ещё и большие деньги получить - вам сказочно повезло

2й подход - для индустрии (и да, вам за это будут платить зарплату  )

[jcxz 184]

В 11.02.2020 в 18:30, xvr сказал:

Понимаю, поэтому и не бросаюсь сразу всё оптимизировать. Ибо это совсем не приоритетная задача.

Внимательно перечитайте мои посты и покажите пальцем где я ратовал за то чтобы "сразу всё оптимизировать"? 

Не надо передёргивать и приписывать мне то, чего я никогда не говорил!

Цитата

А вы тут пытаетесь изобрести свою методологию разработки (сомнительную) и выдать её за непререкаемый всемирный стандарт.

Я не изобретаю тут никаких методологий. А просто указал на ещё один случай использования ассемблера. Из собственного опыта и наблюдений за чужим опытом. То что Вы с ним не согласны, не означает что этого нет. И не означает, что Ваше мнение - единственно верное и правильное, а все чужие - ошибочные.

И вот это:

В 07.02.2020 в 18:51, xvr сказал:

Если код выполняется за заданное время и потребляет заданный объём FLASH и RAM, то какая разница как он там внутри устроен?

Я считаю -  в корне ошибочным мнением. "Ведь оно как-то работает? И так сойдёт!" - это лозунг халтурщиков.

6 часов назад, xvr сказал:

Переход от 1го ко 2му координально рвёт все шаблоны и вгоняет в когнитивный диссонанс (по себе знаю)

И...? Что? Я за свою карьеру работал и по 1-у подходу и по 2-у, и переходил и от 1 к 2 и наоборот. И одновременно работал и по 1-у и 2-у.

6 часов назад, xvr сказал:

В командной работе чистота и понятность исходников

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

 

PS: И все эти новомодные agile и пр. - никак не помогут когда закончатся ресурсы, так легкомысленно потраченные в начале разработки и потребуется переписать всё.