ARM капец в скором будущем?

Itanium это VLIW?

Да. IA-64 (Itanium 1/2) это, скажем так, развитие классических VLIW идей во что-то новое (хоть и не совсем удачное).

Если же присмотреться поближе, то:

1. Условное исполнение есть и в RISC процессорах (например ARMv7). Формально можно натянуть на это и cmov, но это очень ограниченная версия. Ну или условное исполнение в векторных операциях (AVX-512, SVE). Это не делает превращает RISC/CISC/VLIW в EPIC.
2. Спекулятивное исполнение в явном или неявном виде присутствует много где и это не превращает RISC/CISC/VLIW в EPIC.
3. Регистровые окна тоже есть в RISC, например в том же SPARC, но это не превращает RISC/CISC/VLIW в EPIC.
4. Широкая команда тоже уже была в классических VLIW, что не делает из них EPIC.
5. Переименование регистров (это и про вращаемые) тоже присутствует в любом современном RISC/CISC/VLIW процессоре, но в более свободном и полностью аппаратном решении для RISC/CISC OoOE, но это не превращает их в EPIC.
6. Конвейеризация циклов тоже есть много где. В VLIW обычно программная версия, а в OoOE аппаратная (особенность модели исполнения).
7. А вот чего не было, так это явного указания границ группы независимых операций. Причём это можно сделать в любом месте бандла (хоть и с оговорками).

Другими словами, все эти признаки и есть EPIC, но они в том или ином виде присутствуют везде. В E2K есть всё вышеперечисленное, кроме 7 пункта. Формально в моём понимании вот это тоже будет EPIC, только в RISC исполнении:

// group 0
        add     a = b, c    // 1 RISC operation
        sub,sm  d = e, f
        ;; // stop group 0
// group 1
if (p0) mul     g = h, i
        op      ...
        op      ...
        op      ...
        ;; // stop group 1
// group 2
        ...

Вот как бы ты охарактеризовал эту архитектуру? У неё есть условное исполнение, спекулятивное исполнение, явный параллелизм операций (большинство операций в группе независимы), но нет широкой команды.

Товарищ, обещание увеличения зарплаты иногда действует лучше, чем само увеличение зарплаты. Праздник - ожидание праздника. Вон АМД торговала ПР-рейтингом сколько времени? Репутацию изговнякала так, что до сих пор никак не отмоется. А денежки-то - вот они.

Доброе утро однако. :)

У EPIC есть один подвох в кодировке, который тут озвучивали и ты его упускаешь. Это стоп-биты решающие вопрос зависимостей между широкими командами. Компилятор может расположить несколько бандлов друг за другом без стоп-бита и в будущие процессоры могли бы использовать эту информацию для большего параллелизма.

В одну ШК в E2k помещается конечное количество операций и это ограничение на которое уже завязана аппаратура и компилятор. И ничего с этим не сделать.

Мне о других EPIC кроме Itanium неизвестно.

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

В это время

https://www.theregister.com/2021/06/10/intel_sifive_takeover_offer/

Ничего не понял.

VLIW процессоры продают многие компании десятилетиями.

Думаете их никто не покупает?

Покупают, конечно. Из чего не следует их (процессоров) безудержная эффективность при программировании на С++.

В своей нише - встроенных процессов там где ни апгрейда ни нового софта они весьма эффективно работают при наличии нормального компилятора.

«Нормальных» компиляторов ЯВУ для VLIW зафиксировано не было. Весь эффективный код там написан на ассемблере, который больше смахивает на машинный код с байтойобс--м, потому что его ручками под то, что они называют параллелизмом на уровне команд, затачивать надо.

Думаете их никто не покупает?

Билеты МММ тоже покупали. Продать можно любую ерунду, главное уметь продавать.

Да.

Спасибо за развёрнутый ответ. Но к сожалению, это всё мне не поможет, потому что я вижу в ответе ту же мешанину с терминологией, что и везде. Почему-то все довольно свободно размахивают термином VLIW, причём считают, что он всем понятен без дополнительных пояснений. И самое главное, считают, что их понимание термина — единственно верное.

Возможно это связано, а возможно нет, но Intel в Intel® Itanium® Architecture Software Developer’s Manual не упоминает термина VLIW. Они не боятся этого термина, и в других документах он проскакивает, но применительно к Itanium — не видел.

У EPIC есть один подвох в кодировке, который тут озвучивали и ты его упускаешь.

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

Спасибо за развёрнутый ответ. Но к сожалению, это всё мне не поможет, потому что я вижу в ответе ту же мешанину с терминологией, что и везде. Почему-то все довольно свободно размахивают термином VLIW, причём считают, что он всем понятен без дополнительных пояснений. И самое главное, считают, что их понимание термина — единственно верное.

Термины RISC/CISC/VLIW сами по себе довольно расплывчаты. В основном когда говорят про «VLIW» то просто подразумевают ISA с несколькими операциями в широкой команде. Семантика исполнения может быть разная (in-order, OoOE), я уже приводил примеры. Отсюда и появился «Классический VLIW», то есть процессор запускающий на исполнение все операции из широкой команды на одном такте (E2K именно про это). Другими словами, очень простой CPU. Остальные «плюшки» опциональны. В этом плане IA-64 очень не похож на E2K, т.к. у EPIC порядок запуска операций зависит от микроархитектуры. Это огромная разница, как сравнивать in-order суперскаляр и OoOE.

1. Эльбрус-16С — in-order (почти classical, но с доп. плюшками) VLIW CPU.
2. Itanium 9760 — OoOE EPIC CPU.

Возможно это связано, а возможно нет, но Intel в Intel® Itanium® Architecture Software Developer’s Manual не упоминает термина VLIW. Они не боятся этого термина, и в других документах он проскакивает, но применительно к Itanium — не видел.

Я уже писал, что VLIW в IA-64 постольку-постольку. Можно сделать и без него, но это плохо впишется в кодировку, т.к. размер инструкции прийдётся увеличить до 48 бит. Ну ли на крайний случай все переделывать, чтобы уместить инструкцию в 32 бита. В самом крайнем случае инструкция раздуется до 64 бит, что совсем нелепо. Они решили сделать широкую команду в 128 бит и 3 инструкциями по 41 биту и заголовком в 5 бит (тип ШК).

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

Ограничение есть. Это доступные ресурсы (регистры, прочее). Хотя можно сделать бессмысленные группы из большого количества операций.

Отсюда и появился «Классический VLIW», то есть процессор запускающий на исполнение все операции из широкой команды на одном такте (E2K именно про это).

«Классический» VLIW не прячет задержки! Если операция r3 := r1 * r2 требует три такта, а во втором ты пытаешься использовать r3, «классический» VLIW не стопорит конвейер. Ты просто получаешь старое значение r3. Это даже считается фичей, потому что это как бы дополнительные регистры, реализованные в виде линий задержки.

E2k тупо ждёт результата. И судя по доступной информации, это даже тормознее nop’ов.

Да всё именно так. Поэтому я и пишу что он ближе к классике, но не является ей.

Это бессмыссленный аргумент.
Его можно приложить в к тому что VLIW лучше всех остальных но их просто не умеют продавать а все остальные говно но их продают хорошо так как наняли лучших продавцов.

Поэтому я и пишу что он ближе к классике, но не является ей.

И какой смысл использовать термин VLIW, если его использование не упрощает коммуникацию, а только всё усложняет?

И какой смысл использовать термин VLIW, если его использование не упрощает коммуникацию, а только всё усложняет?

Я же потом тебе ответил более понятным языком.

Если сильно упростить, то проще аппаратура — сложнее компилятор.

Ты же сам потом попросил больше подробностей.

Не нужно упрощать. Меня интересует утверждение о том, что e2k ближе к VLIW, чем к EPIC. Я смотрел на описания e2k и ia64, и что-то заявление о близости к чему-то там плохо ложится на то, что я читал.

На крайний случай можно провести параллели между «музыка» и «классическая музыка».

Угу, а 9 женщин родят ребёнка за 1 месяц. Всё так

Вот только недавно узнал от одного человека, что в E2K ISA задержки не прописаны. Они не менялись исключительно из-за недостатка финансирования на новый физдизайн. В Э16С (v6) ситуация немного изменилась и какие-то операции немного изменили задержки. Сам процессор в живую не трогал, поэтому подробностей нет. Так что пересборка актуальна и для E2K.

CPU – Alibaba XuanTie C906 64bit RISC-V core with 32 KB I-cache + 32 KB D-cache

можно на алиэкспресс заказать

https://www.aliexpress.com/item/1005002668194142.html

пересборка актуальна и для E2K

ЧИТД

Недавно, это до qemu или после?

Недавно, это до qemu или после?

Только вчера вечером. До v6 задержки не менялись и я ошибочно предположил, что они зафиксированны в ISA. Можно погонять разный код на ce.mentality.rip. Отчётливо видно что у ld теперь другие задержки. Но я пока не знаю какие ещё операции изменились. Похоже что INT и FP осталась прежними.

F80 скорее всего тоже не изменились.

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

Жду BeagleV

Тут для ждунов не очень радостная картина:

Launch Plans… 2021 End of March… 2021 April

То есть даже сайт как минимум 3 месяца не обновлялся, а то и больше. Что с самим проектом, даже спрашивать боязно…

E2k тупо ждёт результата.

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

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

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

«Классический» VLIW не прячет задержки! Если операция r3 := r1 * r2 требует три такта, а во втором ты пытаешься использовать r3, «классический» VLIW не стопорит конвейер.

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

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

В том, что чаще всего понимают под VLIW, когда речь идёт о каком-нибудь DSP, инструкция просто читает текущее значение регистра. Никаких проверок зависимостей. Этим занимается компилятор. Компилятор может даже использовать это, чтобы увеличить эффективный размер регистрового файла.

Например.

r1      r2      r3      r4      
0       0       0       0       inc r2;         inc r1  
1       1       0       0       add r3, r1, r2; inc r1
2       1       2       0       mul r4, r1, r3; inc r1
3       1       2       0       mov r2, r4;     inc r1
4       0       2       0       nop;            inc r1
5       0       2       4       nop;            inc r1

Предполагается, что у mov, inc и add результат готов на следующем такте, а у mul задержка в 3 такта. Следующая за mul инструкция использует значение из r4, но получает текущее значение. Никаких остановок конвейера.

Отсюда и главная проблема VLIW. Нельзя вообще ничего менять. Нельзя увеличить задержки результатов, это поломает существующие программы. Нельзя даже уменьшать задержки, потому что компилятор мог использовать старые значения регистров аккурат перед тем, как они получали новое значение, и это поломает программы.

Отсюда и главная проблема VLIW. Нельзя вообще ничего менять. Нельзя увеличить задержки результатов, это поломает существующие программы. Нельзя даже уменьшать задержки, потому что компилятор мог использовать старые значения регистров аккурат перед тем, как они получали новое значение, и это поломает программы.

Это всё проблема чисто классических VLIW архитектур с соответствующей простой реализацией в микроархитектуре.

У e2k это не поломает программу, т.к. заявлена обратная совместимость, но никто не гарантирует, что программа будет исполнятся оптимально. Другая проблема, это явные nop. Если они не совпадают с готовностью операндов, то микроархитектура Эльбрусов вытворяет какие-то чудеса и ШК запускаются вообще непонятно как. Эльбрусы в этом плане взяли худшее из того что было.

У Hexagon тоже не поломает программу, но у него не надо явно указывать nop, так как аппаратура может самостоятельно приостанавливать конвейер по необходимости. Хотя проблема оптимального исполнения остаётся в силе, т.к. распланировать инструкции можно было бы иначе.

У последних Itanium уже OoOE и это чуть менее критично. OoOE не такое как обычно это принято в x86/ARM/etc. Если CPU попытается запустить инструкцию с неготовыми операндами, то она просто помещается в конец очереди. Через какое-то время инструкция опять попадёт на исполнение и так будет повторяться до тех пор пока все операнды не будут готовы.

Как видно, ничего не ломается, но есть общая проблема — неоптимальное исполнение. Это если не извращаться с полноценным OoOE для VLIW.

Risc-v чёт сильно смахивает на mips. Почему mips не закопал arm, а risc-v закопает?

ЯННП что ты нарисовал, просто обычный порядок инструкций обычного (не VLIW) процессора, но я понял что ты не знаешь что такое конвейер или pipline если по русски (и это не шутка, один советский инженер-ученый в бородатых годах назвал это «трубопроводом»).

В конвейризованных архитектурах умножение одних и тех же регистров можно запускать хоть каждый такт, главное куда они пишут результат и кто его потом использует, нопы нужны как раз чтоб выровнить конвейер между инструкцией которая считает результат и инструкцией которая его использует, чтоб он не останавливался и не пенальтировал лишние такты. И это ко всем архитектурам относится, если ты сделаешь VLIW который ломается от изменения задержек, то он тупо работать не будет, потому что чтения могут попадать в L1 а могут и не попадать ты никак это в коде не предусмотришь, поэтому надо чтоб процессор умел блокироваться и прожевывать такие ситуации, поэтому изменения задержек приведут максимум к неэффективному исполнению старого кода (не вижу проблемы, современный код постоянно обновляется и перекомпилируется), а к поломке приведет только полная перекомпановка микроархитектуры.

Так что проблема конкретно эльбруса, как единственно действующего влива - это нельзя из него половину скажем выкинуть и сделать маломощный процессор для телефона например, или еще какой эмбедщины. Хотя опять таки так ли критична эмбедщине совместимость с десктопным софтом. Даже в риск-5 для этих вещей предлагают кастрированное ядро с восемью регистрами, там совершенно так же нужно все отдельно компилировать.

ЯННП

Он тебе про Data Hazards и про ISA в которых соблюдение правильного порядка оставлено на компилятор. Конечно приписывать подобное для всех VLIW в корне неверно. Не имеет значения это VLIW или RISC, одинаково зависит от левой пятки создателя этой ISA.

И пока не понятно, надо ли это вендорам, выгодно ли это им или их устраивает существующий порядок дел.

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

если ты сделаешь VLIW который ломается от изменения задержек, то он тупо работать не будет, потому что чтения могут попадать в L1 а могут и не попадать ты никак это в коде не предусмотришь, поэтому надо чтоб процессор умел блокироваться

Мне не надо делать такие VLIW, их уже давно делают. DSP просто тормозят весь конвейер целиком.

There are many different instruction pipeline microarchitectures, and instructions may be executed out-of-order. A hazard occurs when two or more of these simultaneous (possibly out of order) instructions conflict.

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

add r3, r1, r2;
mul r4, r1, r3;
mov r2, r4;

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

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

Ещё раз повторю, что это зависит от левой пятки создателей конкретной ISA.

Взять тот же e2k. Начало его создания было где-то в конце 80-х годов. Тогда транзистры были дорогими и их было очень мало. Было принято решение, что последовательность команд должна учитывать готовность операндов. Так в ШК появились явные nop и требование соблюдать задержки. Однако, в e2k решили обеспечить обратную совместимость. Так в Эльбрусах появился простой механизм обнаружения зависимых команд. Получилась двоякая ситуация. С одной стороны нужно явно указывать nop. С другой же, аппаратура всё же располагает кастрированным механизмом обнаружения зависимых команд.

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

add r3, r1, r2;
mul r4, r1, r3;
mov r2, r4;

В e2k на Э8С это будет выглядеть примерно так:

Time
   0 add r3, r1, r2 // 1, int domain
   1 mul r4, r1, r3 // 4, fp domain
   2 nop
   3 nop
   4 nop
   5 nop            // 2, fp->int bypass latency
   6 nop
   7 mov r2, r4     // 1, int domain

Всё nop надо указывать явно. В ШК можно указать задержку в заголовке, что даёт возможность указать 7 тактовую задержку перед запуском следующей команды.

Если же nop не указывать, то в Э8С, это приведёт к очень нестабильному исполнению, задержки будут очень сильно гулять в большую сторону. В итоге производительность сильно упадёт.

Мы с i-rinat тебе говорим про архитектуры вообще без такого разрешения конфликтов. У mul задержка 4 такта.

   r1 r2 r3 r4 r5                   Result
 T  1  2  3  4  5 // init values
 0                mul r4, r1, r2    T4
 1                add r4, r4, r2    T2
 2           6    sub r5, r4, r3    T3
 3              3 nop
 4           2    add r4, r4, r3    T5
 5           5

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

Какой то свободный проект отказался от RISC-V в пользу POWER от IBM, не помню какой.

Мы с @i-rinat тебе говорим про архитектуры вообще без такого разрешения конфликтов.

И название этой архитектуры «простой последовательный процессор», но как только ты попытаешься добавить ему параллельное и/или внеочередное исполнение тебе сразу по башке прилетят проблемы с зависимостями и ты не можешь их не решать иначе на такой архитектуре ни язык си ничего вообще не может работать правильно.

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

Вы с товарищем @i-rinat несете какую-то дичь, сперва неплохо бы отмечать с какой стороны регистр в вашем псевдоассемблере используется для записи, первый или третий. Ну а во вторых использовать тот же регистр, с тем же значением в следующем такте для перемножеия/итд с другим ничего не мешает, так как это

Read after read (RAR) is not a hazard case.

и не требует разрешения.

И название этой архитектуры «простой последовательный процессор», но как только ты попытаешься добавить ему параллельное и/или внеочередное исполнение тебе сразу по башке прилетят проблемы с зависимостями и ты не можешь их не решать иначе на такой архитектуре ни язык си ничего вообще не может работать правильно.

Нет. Это зависит от левой пятки создателей ISA. Если в ISA будет явно указана задержка перед доступностью результата, то ты ничего с этим не сделаешь. Если же задержки будут идти к каждому CPU с этой ISA, то задержки будут разными. В однотактовом CPU это будет 1 такт и все результаты будут видны сразу, а вот в конвейеризированном скорее всего нет. Можно будет использовать этот регистр в вычислениях до появления результата. В OoOE может быть и так и так, но скорее всего, как и в случае однотактовой машиной, результат будет виден для следующей инструкции. Это вообще не имеет никакого отношения к тому скалярная или суперскалярная машина.

Вы с товарищем i-rinat несете какую-то дичь, сперва неплохо бы отмечать с какой стороны регистр в вашем псевдоассемблере используется для записи, первый или третий.

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

Ну а во вторых использовать тот же регистр, с тем же значением в следующем такте для перемножеия/итд с другим ничего не мешает, так как это

Нет. Ещё раз вернёмся к примеру.

   r1 r2 r3 r4 r5                   Result      Explanation
 T  1  2  3  4  5 // init values
 0                mul r4 = r1, r2    T4          r4_0 = r1 * r2
 1                add r4 = r4, r2    T2          r4_1 = r4 + r2
 2           6    sub r5 = r4, r3    T3          r4 = r4_1; r5_0 = r4 - r3
 3              3 nop                            r5 = r5_0
 4           2    add r4 = r4, r3    T5          r4 = r4_0; r4_2 = r4 + r3
 5           5                                   r4 = r4_2

Read after read (RAR) is not a hazard case.

и не требует разрешения.

Запись (читай видимость результата до его фактического создания) в регистр происходит не в момент запуска инструкции, а когда результат будет готов. Тогда новое значение можно прочитать по этому регистру, до этого читается старое значение. В такой архитектуре вообще может не быть никакого контроля за операндами. А вот такая последовательность вообще может быть UB, если не сказано иначе:

 T                      Result
 0 mul r1 = r0, r1      T4
 1 nop
 2 nop
 3 add r1 = r2, r3      T4
 4                      Что должно быть в r1?

Опять таки, всё зависит от левой пятки создателей ISA.

Запись (читай видимость результата до его фактического создания) в регистр происходит не в момент запуска инструкции, а когда результат будет готов. Тогда новое значение можно прочитать по этому регистру, до этого читается старое значение.

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

достать проект из долгого ящика и пару вещей в нем дописать.

Если ты про qemu-e2k, то у нас возникли небольшие проблемы с перспективой принятия в upstream и у меня пропала мотивация. Когда МЦСТ пойдёт на встречу открытому сообществу и выложит некоторые GNU проекты с поддержкой e2k, то тогда это изменится. Ну или вместо того, чтобы упрекать других в чём-то, сам возьми и добавь поддержку e2k в binutils/llvm если тебе так важна судьба эмулятора.