Jump to content

    

Навык анализа листингов

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-и не удается написать эффективный код, значит у вашего процессора слишком маленькая частота тактирования.
Однозначно надо переходить на более мощный МК, а не мучать ассемблер.  

Share this post


Link to post
Share on other sites
8 hours ago, AHTOXA said:

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

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

 

Share this post


Link to post
Share on other sites
7 hours ago, haker_fox said:

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

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

Share this post


Link to post
Share on other sites
5 hours ago, Forger said:

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

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

Share this post


Link to post
Share on other sites
В 07.02.2020 в 18:51, xvr сказал:

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

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

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

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

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

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

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

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

В 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 есть условное выполнение команд.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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 режиме тоже? Тогда пардон, предложение своё снимаю, и предлагаю оставить всё как было (на С) :angel:

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

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

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

 

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

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

Share this post


Link to post
Share on other sites
3 часа назад, xvr сказал:

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

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

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

 

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

 

Цитата

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

И в нём тоже.

Share this post


Link to post
Share on other sites
9 часов назад, jcxz сказал:

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
19 hours ago, jcxz said:

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

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

19 hours ago, jcxz said:

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

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

19 hours ago, jcxz said:

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

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

19 hours ago, jcxz said:

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

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

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

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

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

19 hours ago, jcxz said:

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

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

Share this post


Link to post
Share on other sites

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

 

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

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

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

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

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

Share this post


Link to post
Share on other sites
11 minutes ago, xvr said:

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

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

:good:

Share this post


Link to post
Share on other sites
В 11.02.2020 в 18:30, xvr сказал:

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

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

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

Цитата

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

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

И вот это:

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

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

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

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

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now