Перейти к содержанию
    

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

Добрый день, коллеги! Возник академический вопрос. А каким образом в современных условиях, когда уже не то, что Си, но Си++ активно используется, поддерживается навык разбора листингов после компилятора? Ведь в том же Cortex-M0 не так уж и мало команд, не говоря уже о более старших архитектурах. При постоянном использовании языков выского уровня навык программирования, или даже анализа, листингов должен теряться. Кто-то, возможно, вообще ни разу не программировал на ассемблере. Могут ли уважаемые участники поделиться своим опытом? Ну, например, для поддержания этого навыка нужно делать один простенький проект в месяц на чистом ассемблере))) Спасибо!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

31 minutes ago, haker_fox said:

 навык разбора листингов после компилятора?

Начать стоит с того, как часто приходится это делать?

 

31 minutes ago, haker_fox said:

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

Сомневаюсь, что этот "навык" так уж необходим в повседневной практике )

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

40 minutes ago, haker_fox said:

Спасибо!

Ну во первых, C++ в этом деле надо забыть.
Т.е. если хотите видеть хороший чистый ассемблер под каждым оператором, то используйте только C.
Во-вторых просмотр ассемблера - одна из первейших вещей при отладке. Сейчас одним из лучших отладчиков для контроля ассемблерного кода под каждой инструкцией  С будет отладчик от Segger-а.  

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 minutes ago, Forger said:

Начать стоит с того, как часто приходится это делать?

Ответ тут будет риторическим) При первом хардфолте, например...

3 minutes ago, Forger said:

омневаюсь, что этот "навык" так уж необходим в повседневной практике )

Вполне возможно, учитывая объёмы памяти современных МК, можно уписаться))) Но всё-таки вопрос этот меня заинтересовал, ибо иногда возникает вопрос оптимизации некого алгоритма, и хочется быть уверенным, что компилятор сделал всё возможное. А если не справился, то делать самому.

3 minutes ago, AlexandrY said:

инструкцией  С будет отладчик от Segger-а.

Чем же он так хорош в сравнении с тем же IAR?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

4 minutes ago, haker_fox said:

Ответ тут будет риторическим) При первом хардфолте, например...

И так ли часто вы сходу не можете указать причину хардфолта в своем проекте?

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

Ищется обычно достаточно быстро - локализацией и анализом кода, до добавления которого все работало. ASM-листинги для этого анализировать никогда не приходилось. Ходить по asm-коду - крайне редко.

 

4 minutes ago, haker_fox said:

Вполне возможно, учитывая объёмы памяти современных МК, можно уписаться)))

Вот именно! Равно как и с производительностью, если все делать по уму ))

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

18 минут назад, AlexandrY сказал:

Т.е. если хотите видеть хороший чистый ассемблер под каждым оператором, то используйте только C.

Пфф... Ну-ну.

Даже на -O0 или -O1 компайлер может выдать полную дичь, вместо ожидаемого. Хоть и рабочую.

 

20 минут назад, AlexandrY сказал:

Во-вторых просмотр ассемблера - одна из первейших вещей при отладке.

+1. Если кусок кода ведет себя хрен пойми как - смотрю в листинг. Из него многое становится ясно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

14 minutes ago, Forger said:

Ходить по asm-коду - крайне редко.

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

9 minutes ago, Arlleex said:

+1. Если кусок кода ведет себя хрен пойми как - смотрю в листинг.

А как вы учили систему команд? Ведь при просмотре листинга должна складыватьс я картина, что делает процессор. Во времена AVR и PIC  я начинал с ассемблера, и при переходе на Си листинги были понятны. Армы я начал сразу программировать на ЯВУ, поэтому полного понимания выхлопа компилятора нет(((

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 минуту назад, haker_fox сказал:

А как вы учили систему команд?

Я не суперпрофи, конечно. Но 90% команд - похожи между собой от проца к процу.

Ну и систему команд перед глазами держу просто, со временем запоминается.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Хожу по окну дизассемблера Keil. Если в какой-то команде сомневаюсь, листаю книгу Дж. Ю. Просто поиском забиваю команду.
В C++ Keil не выдаёт листинга, удобного для изучения. Вот для C давал *.txt файл, там всё было красиво. А для C++ V6.13 такого нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 minutes ago, Arlleex said:

Ну и систему команд перед глазами держу просто, со временем запоминается.

Понятно) Я уж было хотел точно для практики простенький проектик слепить на чистом асме) Хотя, почему бы и нет...

1 minute ago, ViKo said:

В C++ Keil не выдаёт листинга, удобного для изучения.

Это как????:biggrin: Гнать такой компилятор в шею... и не только в шею...)))) (Из фильма).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 минуты назад, haker_fox сказал:

Это как????:biggrin: Гнать такой компилятор в шею... и не только в шею...)))) (Из фильма).

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, haker_fox said:

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

Единственный (ну почти единственный) кому потребуется постоянно рассматривать листинги после компилятора - это разработчик этого самого компилятора :angel:

36 minutes ago, haker_fox said:

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

Если возникла такая необходимость - надо сменить компилятор :blum3: Например, что бы что то наоптимизировать в ассемблере после gcc нужно очень (нет ОЧЕНЬ) сильно постараться.

Может понадобится ассемблер если вы делаете какие то ну очень низкоуровневые (и железно специфичные) вещи, которые в С/С++ просто не выражаются.

И ещё может понадобится ассемблер (точне не столько ассемблер, сколько знание архитектуры целевого CPU) если вы занимаетесь какой то очень архитектурно специфичной оптимизацией (например пытаетесь заставить этот %^%^&^*& компилятор векторизовать цикл). Но для CPU типа ARM Cortex M<чего нибудь> вам с этим вряд ли придётся столкнуться

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 часа назад, haker_fox сказал:

Могут ли уважаемые участники поделиться своим опытом? Ну, например, для поддержания этого навыка нужно делать один простенький проект в месяц на чистом ассемблере))) Спасибо!

Ерунда. Последний раз почти полностью на ассемблере разрабатывал проект уже >=13 лет назад. И тем не менее "навык" сей не потерял. Хоть это была совершенно другая архитектура. После коей изучил уже несколько других. Листинги смотрю не постоянно, но периодически. Иногда - это кратчайший путь нахождения ошибки в своём коде.

Имхо: Если человек не знает ассемблера используемого ядра (пускай с заглядыванием в мануал описания команд) и не умеет понять листинг - то он однозначно не может считаться профи в embedded-программировании. Вывод сей сделал на основе своего многолетнего опыта в этой области. Ещё раз - имха.

1 час назад, haker_fox сказал:

Вполне возможно, учитывая объёмы памяти современных МК, можно уписаться))) Но всё-таки вопрос этот меня заинтересовал, ибо иногда возникает вопрос оптимизации некого алгоритма, и хочется быть уверенным, что компилятор сделал всё возможное. А если не справился, то делать самому.

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

1) Лучше изучить ассемблер и ядро;

или:

2) Искать ошибки в своём коде.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

17 minutes ago, xvr said:

Единственный (ну почти единственный) кому потребуется постоянно рассматривать листинги после компилятора - это разработчик этого самого компилятора

Не согласен, ИМХО. Иногда компиляторы ошибаются. И это не единичный случай.

18 minutes ago, xvr said:

Если возникла такая необходимость - надо сменить компилятор

Интересное мнение. Но всё же: как вы будете разбираться, если не работает или работает медленно кусок кода? При этом на ЯВУ ошибки нет.

5 minutes ago, jcxz said:

и не умеет понять листинг - то он однозначно не может считаться профи в embedded-программировании

Здесь согласен на 100 % ! Но считаю своё умение недостаточным, и хочу улучшить и укрепить его. А заодно и своё конкурентное преимущество перед коллегами))))))))

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

58 минут назад, ViKo сказал:

Хожу по окну дизассемблера Keil. Если в какой-то команде сомневаюсь, листаю книгу Дж. Ю. Просто поиском забиваю команду.

Зачем?  Есть же "Cortex-M3/M4F Instruction Set. TECHNICAL USER'S MANUAL"

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...