Наивно, условно исполняемые инструкции кажутся мне отличной идеей.
Поскольку я читал больше о наборах команд ARM (и ARM-like) (Thumb2, Unicore, AArch64), я обнаружил, что им не хватает битов для условного выполнения.
Почему условное выполнение отсутствует в каждом из них?
Было ли условное исполнение ошибкой в то время или последующие изменения сделали его дорогостоящей тратой битов инструкций?
Общее требование - современные системы имеют лучшие отраслевые предсказатели, а компиляторы намного более продвинуты, поэтому их стоимость на пространстве кодирования команд не оправдана.
Это от Обзор набора инструкций ARMv8
Набор команд A64 не включает понятие условное исполнение. Бенчмаркинг показывает, что современная ветка предиктора работают достаточно хорошо, что предварительное выполнение инструкций не дает достаточной пользы для обоснования ее значительного использования opcode space и его стоимость внедрения в расширенном реализации.
И он продолжает
Очень маленький набор инструкций "условной обработки данных" предоставлена. Эти инструкции безоговорочно выполняются, но используют флаги состояния в качестве дополнительного ввода инструкции. Этот набор имеет было показано, что оно выгодно в ситуациях, когда условные ветки плохо прогнозировать или в противном случае неэффективны.
Еще одна статья под названием Торговое условное исполнение для большего количества регистров на процессорах ARM утверждает:
... условное исполнение занимает драгоценное пространство условия кодируются в 4-разрядный селектор кода условия на каждом 32-разрядная команда ARM. Кроме того, только небольшие проценты инструкции фактически условны в современных встроенных приложения и условное выполнение могут даже не привести к повышение производительности на современных встроенных процессорах.
Одна из причин - из-за кодировки команд.
Практически, вы не можете втиснуть еще четыре бита в ограниченное 16-битное пространство, в то время как даже недостаточно места для 3 старших битов операндов регистра, и они должны быть уменьшены до поднабора только из 8 регистров. Обратите внимание, что в thumb2 у вас есть отдельная инструкция IT (E) для выбора условий для следующих 4 инструкций. Вы не можете сохранить условие в той же инструкции по причине, указанной выше.
Для AArch64 количество регистров было удвоено по сравнению с 32-битным ARM, но опять же у вас нет оставшихся битов для новых 3 старших битов регистров. Если вы хотите использовать старую кодировку, вы должны "заимствовать" либо из узкого 12-битного непосредственного, либо из 4-битного условия. 12 бит уже слишком малы по сравнению с другими архитектурами RISC, такими как MIPS, и уменьшение числа делает все хуже, поэтому удаление условия - лучший выбор. Поскольку предсказание ветвлений становится все более и более продвинутым, это не будет большой проблемой. Это также облегчает реализацию внеочередного выполнения, потому что теперь есть еще одна вещь, которую нужно переименовать и заботиться о ней.
Условное выполнение является хорошим выбором при реализации многих вспомогательных подпрограмм или операций с перестановкой битов, таких как сортировка, манипулирование списком или деревом, преобразование числа в строку, sqrt или длинное деление. Мы могли бы добавить драйверы UART и извлечь битовые поля в маршрутизаторах. У них высокое отношение ветвлений к нерасветвлениям, а также непредсказуемость.
Однако, как только вы выйдете за пределы самого низкого уровня услуг (или увеличите уровень абстракции с помощью языка более высокого уровня), код будет выглядеть совершенно по-другому: блоки кода внутри различных ветвей условий состоят из перемещения данных и вызова подпрограмм. Здесь преимущества этих дополнительных 4 бит быстро исчезают. Это не только личное развитие, но и культурное. Культурное программирование выросло из неструктурированного (Basic, Fortran, Assembler) в структурное. Различные парадигмы программирования лучше поддерживаются и в разных архитектурах набора команд.
Технологическим компромиссом могла бы стать возможность сжатия пятибитового поля cond.S до четырех или трех наиболее часто используемых комбинаций.
Несколько неверно сказать, что условное исполнение отсутствует в ARMv8. Проблема заключается в том, чтобы понять, почему вы не хотите выполнять некоторые инструкции. Возможно, в ранние дни ARM фактическое неисполнение инструкций имело значение (для власти или что-то еще), но сегодня значимость этой функции заключается в том, что она позволяет вам избегать ветвей для небольших немых прыжков, например код вроде a = (b > 0≤1: 2). Такого рода вещи более распространены, чем вы можете себе представить - концептуально это такие вещи, как MAX/MIN или ABS (хотя для некоторых процессоров могут быть инструкции для выполнения этих конкретных задач).
В ARMv8, хотя нет общих условно исполняемых инструкций, есть несколько инструкций, которые выполняют конкретную задачу, которую я описываю, а именно позволяю избегать ветвления для коротких немых прыжков; CSEL является наиболее очевидным примером, хотя существуют другие случаи (например, условная настройка условий) для обработки других общих паттернов (в этом случае шаблон оценки короткого замыкания на C).
ИМХО, что сделал ARM, вот что имеет наибольший смысл. Они извлекли особенность условного исполнения, которая остается ценной для современных процессоров (избегайте многих веток), изменяя детали реализации в соответствии с микро-архитектурой современных процессоров.
На старом ARM v4 условные инструкции только сохраняли время, если была высокая вероятность того, что они в конечном итоге будут выполнены, или если вероятность будет около 50%, тогда, если их было всего 2-4 из них ряд. Если они не выполнялись, то это было потрачено впустую, чтобы пройти мимо них, а также накладные расходы, связанные с использованием ветки, чтобы пройти мимо них. Если они выполняются, ветвь будет извлечена, но не будет выполнена.
Незначительная неприятность заключается в том, что при отладке размещение прерывания по условной инструкции всегда приводило к перерыву в этой команде независимо от условия (если только там не было действительно умного отладчика, которого у моей компании не было).
Точно так же, как и в слове "отсрочка", когда мипы становятся трюком (в то время), условное выполнение в руке - это трюк (в то время), так же как и pc - две инструкции вперед. Теперь по дороге, насколько они влияют? Будет ли предсказатель ветвей ARMs действительно иметь такую большую разницу или является реальным ответом на то, что им нужно больше битов в 32-битовом слове инструкции и как большой палец первая и самая простая вещь, чтобы избавиться от битов условия.
не так уж сложно выполнить некоторые тесты производительности, чтобы понять, насколько хороши или верны предсказатели ветвей на самом деле, я попробовал это с безусловными ветвями на arm11, получив старую архитектуру сейчас, но все еще широко используемую. В лучшем случае было трудно получить предсказание ветвей, чтобы показать какое-либо улучшение, и никоим образом, форма или форма не могли конкурировать с условным исполнением. Я не повторил этот опыт ни на чем в коре - семье.
"Почему условно исполняемых инструкций нет..." "Было ли условное выполнение ошибкой в то время, или последующие изменения сделали это дорогой тратой инструкций?"
Статья в Википедии на темуПредикатность - недостатки"содержит немного информации:
"Недостатки
Основной недостаток предиката в увеличенном пространстве кодирования. В типичных реализациях каждая инструкция резервирует битовое поле для предиката, определяющего, при каких условиях эта инструкция должна оказывать влияние. Когда доступная память ограничена, как на встроенных устройствах, эта стоимость может быть чрезмерной. Однако некоторые архитектуры, такие как Thumb-2, могут избежать этой проблемы (см. ниже). Другие вреды следующие:
- Предикат усложняет аппаратное обеспечение, добавляя уровни логики для критических путей и потенциально снижая тактовую частоту.
- Предикатный блок включает в себя циклы для всех операций, поэтому более короткие пути могут занять больше времени и быть оштрафованы.
Предикат наиболее эффективен, когда пути сбалансированы или когда наиболее часто выполняется самый длинный путь, но определить такой путь очень сложно во время компиляции, даже при наличии информации профилирования.
...
В архитектуре ARM исходный 32-битный набор команд обеспечивает функцию, называемую условным выполнением, которая позволяет большинству команд быть предикированными одним из 13 предикатов, которые основаны на некоторой комбинации четырех кодов условий, установленных предыдущей инструкцией. Набор команд ARM Thumb (1994) отбросил условное выполнение, чтобы уменьшить размер инструкций, чтобы они могли уместиться в 16 бит, но его преемник, Thumb-2 (2003), преодолел эту проблему, используя специальную инструкцию, которая не имеет никакого эффекта, кроме как предоставить Предикаты для следующих четырех инструкций. 64-битный набор команд, представленный в ARMv8-A (2011), заменил условное выполнение инструкциями условного выбора. ".
В статье Джозефа А. Фишера, Паоло Фарабоски и Клиффа Янга "Встроенные вычисления: подход VLIW к архитектуре, компиляторам и инструментам" на странице 172:
"... полное предопределение усложняет аппаратное обеспечение, ISA и компилятор. В отличие от спекуляций, которые благоприятствуют более глубоким конвейерам и более быстрым тактам, предикация добавляет уровни логики к критическим путям и потенциально снижает тактовую частоту. Операнды предикатов используют драгоценные биты кодирования во всех инструкции и обход операций с предикатными операндами значительно усложняет логику пересылки.Преимущества предиката для ациклического или "ориентированного на контроль" кода были предметом оживленной академической и коммерческой дискуссии, и до сих пор не решено, оправдывают ли преимущества предикации огромные затраты на оборудование для поддержки полной предикации.
Аргумент между полной предикацией и частичной предикацией еще более тонкий. Полная предикация более выразительна и позволяет компилятору предикатировать блоки, содержащие любую комбинацию операций. Частичная предикация требует агрессивной спекуляции и встраивает некоторые внутренние ограничения (например, она не может предикатировать блоки, содержащие операции вызова). С точки зрения сложности реализации, полное предикация предъявляет гораздо более высокие требования к кодировкам команд и микроархитектуре, как описано ранее, тогда как частичное предикация с операциями выбора хорошо подходит для большинства микроархитектур и путей данных и не влияет на сложность, площадь или скорость.,
Предикатирование во встроенном домене
Во встроенном домене трудно оправдать штраф за размер кода большого набора регистров предикатов. Полная предикация предполагает философию "предоплаты", в которой стоимость оборудования предиката должна оплачиваться независимо от того, как часто он используется. Например, добавление 6 битов предиката для адресации 64 предикатов помогло увеличить кодировку IPF до 42 битов. за операцию - подход, который будет чрезмерно дорогостоящим для встроенного процессора.... ".
Стоимость, TDP и патенты, даже уровень технической квалификации, необходимый для разработки конкурирующего продукта, - все это входит в игру. В этом случае это была экономическая выгода, полученная благодаря обновленным методам кодирования. То, что, как считалось, было необходимо, не использовалось в действительности или, по крайней мере, неэффективно (за счет затрат на его реализацию).
Как объяснено в другом ответе, руководство ARM мало говорит о причине, меньше о ней, чем руководство RISC, вот что ARM должен был сказать на странице 8 "Обзора набора инструкций ARMv8":
"3 A64 ОБЗОР
Набор команд A64 обеспечивает функциональность, аналогичную наборам команд A32 и T32 в AArch32 или ARMv7. Однако так же, как добавление 32-битных инструкций к набору команд T32 рационализировало некоторые из ARM ISA поведения, набор инструкций A64 включает дальнейшие рационализации. Основные моменты нового набора команд следующие:
...
Снижение обусловленности. Меньше инструкций может установить флаги условия. Только условные ветки и несколько инструкций по обработке данных читают флаги условий. Условное или предикатное выполнение не предоставляется, и нет эквивалента ИТ-инструкции T32s (см. § 3.2).
...
3.2 Условные инструкции
Набор команд A64 не включает концепцию предикативного или условного выполнения. Сравнительный анализ показывает, что современные предикторы ветвлений работают достаточно хорошо, так что предикатное выполнение инструкций не дает достаточных преимуществ для оправдания значительного использования пространства кода операции и стоимости его реализации в расширенных реализациях.Предоставляется очень небольшой набор инструкций "условной обработки данных". Эти инструкции выполняются безоговорочно, но используют флаги условия в качестве дополнительного ввода в инструкцию. Было показано, что этот набор полезен в ситуациях, когда условные ветки плохо предсказывают или иным образом неэффективны.
Дополнительная информация приведена в разделе "4.3. Коды условий", но она не объясняет, каким образом было принято решение.
Разработчики RISC-V ISA (не связанного недавно разработанного ISA) объясняют (http://riscv.org/spec/riscv-spec-v2.0.pdf на странице 23) кое-что из того, что входит в проектирование процессора:
"Условные ветки были разработаны для включения операций арифметического сравнения между двумя регистрами (как это также делается в PA-RISC, Xtensa и MIPS R6) вместо использования кодов условий (x86, ARM, SPARC, PowerPC) или для сравнения только одного регистр против нуля (Альфа, MIPS) или два регистра только для равенства (MIPS). Этот дизайн был мотивирован наблюдением, что объединенная команда сравнения и ветвления вписывается в обычный конвейер, избегая дополнительного состояния кода условия или использования временный регистр, уменьшает статический размер кода и трафик выборки динамических команд.
...
Как условное перемещение, так и предикатные инструкции добавляют сложность микроархитектурам с неупорядоченным порядком, добавляя неявный третий исходный операнд из-за необходимости копировать исходное значение целевого архитектурного регистра в переименованный физический регистр назначения, если предикат имеет значение false, Кроме того, статические решения во время компиляции использовать предикацию вместо ветвей могут привести к снижению производительности входных данных, не включенных в обучающий набор по компилятору, особенно с учетом того, что непредсказуемые ветки редки и становятся реже по мере совершенствования методов прогнозирования ветвей.
Мы отмечаем, что существуют различные методы микроархитектуры для динамического преобразования непредсказуемых коротких прямых ветвлений в код с внутренним предсказанием, чтобы избежать затрат на очистку конвейеров при неправильном предсказании ветвей [6, 10, 9], и они были реализованы в коммерческих процессорах [17].
Простейшие методики просто уменьшают штраф за восстановление после непредсказуемой короткой прямой ветки, просто сбрасывая команды в тени ветки вместо всего конвейера выборки, или выбирая инструкции с обеих сторон, используя широкие интервалы выборки команд или выборки свободных команд. Более сложные методы для ядер, вышедших из строя, добавляют внутренние предикаты для инструкций в тени ветвления, причем значение внутреннего предиката записывается инструкцией ветвления, что позволяет выполнять ветвь и следующие инструкции спекулятивно и не в порядке относительно другой код [17].
[6]Тимоти Х. Хейл и Джеймс Э. Смит. Избирательное выполнение двух путей. Технический отчет, Uni- Версис Висконсин - Мэдисон, ноябрь 1996 года.
[9]Хисун Ким, Онур Мутлу, Джаред Старк и Йель Н. Патт. Ветви желаний: объединение условного ветвления и предикации для адаптивного предикатного исполнения. В материалах 38-го ежегодного Международного симпозиума IEEE/ACM по микроархитектуре, MICRO 38, стр. 43–54, 2005.
[10]А. Клаузер, Т. Остин, Д. Грюнвальд и Б. Колдер. Динамическое предопределение гамака для непредсказуемых архитектур набора команд. В материалах Международной конференции 1998 года по параллельным архитектурам и методам компиляции, PACT 98, Вашингтон, округ Колумбия, США, 1998.
[17]Баларам Синхарой, Р. Калла, У.Дж. Старке, Ш.К.Ле, Р.Карнони, Дж.А. Ван Норстранд, Б.Дж. Рончетти, Дж. Стуэчели, Дж. Леенстра, Г.Л. Гатри, Д.К. Нгуен, Б. Бланер, К.Ф. Марино, Э. Реттер и П. Уильямс. Многоядерный серверный процессор IBM POWER7. IBM Journal of Research и Development, 55 (3): 1–1, 2011.
Удаление предикатных инструкций на 64-битном ARM освобождает четыре бита при кодировании каждой инструкции, это позволяет добавлять один бит к каждому полю регистров, таким образом удваивая количество регистров.
На мой взгляд, это ошибка - пропускать способность elison в серверном процессоре, прикрепленном к Fabric, но компромиссы сделаны. Это не ошибка (иметь хорошую реализацию), это дорого, это не пустая трата (биты умны и занимаются своим делом). Условия были проще/лучше.
Это как любое расширение процессора или добавление графического процессора; если вы можете умело использовать свои инструменты, тогда вам пора идти, иначе соберитесь с силами.
Цитата из Википедии: "Согласно различным оценкам, TSX может обеспечить примерно 40% более быстрое выполнение приложений в определенных рабочих нагрузках и в 4–5 раз больше транзакций базы данных в секунду (TPS)".
Это "дорого" (в некоторых ситуациях), но важно для текущего стиля программирования или, более пессимистично, для получения гораздо более высоких результатов в синтетических тестах.
Когда-нибудь это будет так же легко, как и у Lego, и вы сможете попросить "это" собраться и выполнить свою ставку; до этого Процессор ДОЛЖЕН поддерживать лени Программиста (и создателей компиляторов) - таким образом, редкость Программ, которые могут работать в основном на GPU (но мы добираемся туда).
Следовательно, удаление (замечательных) функций, которые считаются нежелательными или не были реализованы экономически эффективным и конкурентным способом.
Таким образом, TSX правил в настоящее время; но процессорам ARM тоже нужны модные потоки для их Fabric.
Ссылки на URL:
AMD: https://en.wikipedia.org/wiki/Advanced_Synchronization_Facility
Intel: https://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions
,