Постпроцесс `objdump --disassemble` с подсчетом циклов ARM

Есть ли сценарий для пост-обработки некоторых выходных данных objdump --disassemble, чтобы аннотировать количество циклов? Особенно для семейства ARM. В большинстве случаев это будет только сопоставление шаблона с поиском в таблице для подсчета. Я предполагаю, что могут понадобиться аннотации, такие как +5M для пяти циклов памяти. Perl, python, bash, C и т. д. в порядке. Я думаю, что это можно сделать в общем случае, но меня интересует ARM, который имеет ортогональный набор инструкций. Вот ветка на 68HC11, делающая то же самое. Сценарию потребуется параметр ЦП model для выбора подходящего количества циклов; Я думаю, что эти значения уже есть в описании машины gcc.

Я не думаю, что для этого есть переключатель objdump, но RTFM было бы здорово.

Редактировать: Чтобы уточнить, такие предположения, как подсистема памяти в лучшем случае, которая будет иметь место, когда код выполняется из кеша, в порядке. Целью является не 100% точный подсчет циклов, как на какой-нибудь работающей машине. Можно получить разумную оценку, иначе разработка компилятора была бы невозможна.

Как указывает DWelch, простой промежуточный итог невозможен с глубокой конвейерной архитектурой, такой как более поздние чипы Cortex. Постобработка objdump должна была смотреть на окружающие коды операций. Плагин gcc, скорее всего, сможет это сделать, и, поскольку он новый (4.5+), я не думаю, что такая вещь существует. Скрипт для ARM926, безусловно, возможен и достаточно прост.

Задержка памяти не имеет значения. Контроллер памяти вроде другой CPU. Он занимается своими делами, пока процессор занимается арифметикой и т. д. Хороший/хорошо настроенный алгоритм будет параллельным. доступ к памяти с вычислениями. Подсчитывая загрузки/хранения и циклы, вы можете определить, насколько достигается параллелизм при активном профилировании с помощью таймера. Конвейер важен из-за блокировок между регистрами, но количество циклов для базовых блоков может быть достоверно определено. рассчитываются и используются даже на современных процессорах ARM; это слишком сложно для простого скрипта.


person artless noise    schedule 18.02.2013    source источник
comment
К вашему сведению, ARM не публикует время цикла для своих последних процессоров (например, Cortex-A5/A7/A15).   -  person Marat Dukhan    schedule 18.02.2013
comment
@Maratyszcza: Интересно. Я посмотрел и не вижу ни одного. Там написано низкое количество циклов для ARM7-a, поэтому я предполагаю, что это означает один такт, за исключением проблем с памятью. Как тогда можно написать компилятор? Gcc, кажется, имеет описание. gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/arm/   -  person artless noise    schedule 18.02.2013
comment
Разные ЦП ARMv7-A имеют разное время цикла (и код, оптимизированный для одного ЦП, будет неоптимальным для другого).   -  person Marat Dukhan    schedule 19.02.2013


Ответы (2)


Существует онлайн-инструмент, который оценивает количество циклов Cortex-A8. Однако этот ЦП довольно старый, и программы, оптимизированные для него, могут быть неоптимальными на более новых ЦП.

AFAIK ARM также предоставляет эмуляторы Cortex-A9 и Cortex-A5 с точностью до цикла. в их программном обеспечении RVDS, но это довольно дорого.

person Marat Dukhan    schedule 18.02.2013
comment
+1 за что-то, демонстрирующее, что это возможно; только дурак может подумать, что эти инструменты точны на 100%. Я надеюсь на что-то с открытым исходным кодом и более общее; В частности, у меня нет Cortex. - person artless noise; 19.02.2013
comment
Быстрые модели не являются циклически точными. Чтобы пошутить, это были бы медленные модели :) - нет общедоступных моделей с точностью до цикла. - person Charles; 21.02.2015

Количество циклов нельзя оценить, взглянув только на инструкцию на современном высокопроизводительном ARM. Существует много состояний времени выполнения, которые влияют на скорость вывода инструкций из эксплуатации в реальном мире. Существуют ли необходимые данные в кеше? Зависит ли инструкция от результатов предыдущей инструкции? Если да, то какие задержки устраняет модуль пересылки? Насколько заполнен буфер загрузки/хранения? О каком отображении памяти идет речь? Насколько заполнены конвейеры процессора, необходимые для этой инструкции? Есть ли инструкции по синхронизации в потоке? Выдвинули ли предположения какие-то данные, от которых они зависят? В каком состоянии находится средство переименования реестра? Заполняют ли конвейер условные инструкции, или декодер был достаточно умен, чтобы полностью их пропустить? Каковы соотношения между тактовой частотой ядра и тактовой частотой шины и памяти? Каков размер таблицы прогнозирования ветвлений?

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

person Variable Length Coder    schedule 18.02.2013
comment
не имеет значения, нулевое состояние ожидания или нет. ядра рук и периферийные устройства вокруг них, аксиальный/амба-интерфейс поставщиков чипов и т. д. — все это определяет скорость выполнения. Если вы хотите узнать, насколько быстро что-то работает на конкретной плате, запустите его на этой плате, иначе в лучшем случае это будет лишь грубое предположение, и ожидается, что оно будет неверным по какому-то факту или 2 раза неправильно, 4 раза неправильно, 10 раз неправильно и т. д. в любом направлении. - person old_timer; 18.02.2013
comment
это верно для большинства конвейерных архитектур, а не только для рук - person old_timer; 18.02.2013
comment
детерминированные архитектуры, такие как pics (конечно, не mips pic) и 8051 и 68hc11, 6502, 8088, 8086 и длинный список других, вы можете легко создать инструмент, который вычисляет это время выполнения. - person old_timer; 18.02.2013
comment
В настоящее время я смотрю на -fdump-rtl-all. Конечно, gcc имеет некоторое представление о том, сколько времени занимают инструкции. Я понимаю, что интерфейс AMBA может отличаться. Это память, не так ли? Я хочу предположить, что ядро ​​питается инструкциями. ARM5 и более ранние версии, безусловно, детерминированы. Я совершенно уверен, что все они детерминированы, возможно, слишком сложный/глубокий конвейер более уместен? Я думаю, вряд ли это будет 10x неправильно. Если это так, вам нужно посмотреть параметры, которые вы передаете компилятору, ИЛИ компилятору необходимо обновить описание машины. - person artless noise; 19.02.2013
comment
Количество циклов плюс количество операций ввода/вывода могут дать полезную информацию. Циклы ЦП будут сбалансированы с шиной памяти в хорошей процедуре. Вы уверены, что вы, ребята, настроены на поражение? Я действительно сошел с ума? Если да, то удалю вопрос. - person artless noise; 19.02.2013
comment
@BillPringlemeir: не сходите с ума, и нет необходимости удалять вопрос, но дело в том, что новые процессоры с большими задержками доступа к памяти слишком недетерминированы, чтобы статический анализ был надежным. В конечном итоге вы тратите время на оптимизацию частей кода, которые не влияют на фактическую производительность, игнорируя при этом те части, которые наносят вам вред (т. - person unixsmurf; 20.02.2013
comment
Взгляните на описания машин GCC (gcc.gnu.org/onlinedocs/gccint/ Machine-Desc.html), чтобы получить более точное представление о том, какую информацию GCC имеет об инструкции. В частности, GCC отслеживает слоты задержки, требуемые инструкцией, и конвейеры процессора, предоставляемые архитектурой. Похоже, что он не предсказывает количество тактовых импульсов инструкций; это просто использование атрибутов инструкций и конвейера для улучшения порядка инструкций. - person mkfs; 05.05.2013
comment
@mkfs Я думал о arm.c в gcc и часть информации о стоимости, закодированной там. В некоторых случаях они кажутся подсчетами инструкций? Не то чтобы они были точными по циклам, но в некоторых случаях компилятор использует их для выбора кодов операций. - person artless noise; 17.05.2013
comment
RE: arm.c -- похоже, он предоставляет информацию оптимизатору GCC, поэтому вы можете получить к нему доступ при компиляции с параметрами -ftree-vectorizer-verbose=3 и/или -fdump-tree-vect. Однако эта информация недоступна в objdump, поскольку она не включена в модуль libopcodes binutils для ARM: repo.or.cz/w/binutils.git/blob/HEAD:/opcodes/arm-dis.c . Это означает, что вам придется извлечь код генерации стоимости из GCC или (возможно) передать GCC необработанный ассемблер и заставить его выдать информацию о стоимости, используя параметры GCC -fdump (если они поддерживаются). - person mkfs; 04.06.2013