Развитие VLIW архитектуры процессоров

Теперь, развитие идеи номер2 - о микропотоках. Как применить эту идею и сильно увеличить плотность кода на суперскалярах, без усложнения или даже с упрощением механизмов ОоО.

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

У каждого микропотока со своим предикатом существует свой текущий регистр (соотвественно, для 4 предикатов одновременно существует 4 текущих регистра по произволу компилятора выбранных из, допустим, 32 РОН).

В строгом варианте (если предикат не рекомендует, а задаёт порядок исполнения) это вырождается во VLIW с переменной длиной слота (от 1 до 4), что полностью решает одну из проблему VLIW "чем забивать слоты, если код как-то не подходит под VLIW?!"). Это не только решает бОльшую часть проблем компилятора VLIW, это ещё и пропорционально ускоряет выполнение на типичном коде: нет пустых слотов - нет штрафов за "малопоточность" кода, при этом пиковая производительность (где код позволяет, а компилятор сумел) - всё же 4 слота, 4 потока, что очень дофига. А пустые слоты это трата полосы памяти и штрафы за очистку конвеера.

Если код того же Эльбруса приводить к такому виду, проигрышей нет (у Эльбруса 3 слота), а выигрыш безусловен и на "малопоточном" коде, где можно испольовать только один код, и по максимальному числу потоков.
Все преимущества VLIW без недостатков пустых слотов. То есть, такая схема решает значительную часть проблем VLIW, не привнося новых недостатков.

С учётом общего увеличения плотности кода идеей1, тот же Эльбрус можно сделать в разы(!!!) эффективнее с одновременным некоторым упрощением компилятора и без переноса сложности в железо.

...

Но я, всё же, рассматриваю предикаты как подсказку, а не жёсткий VLIW, чтобы
а) убрать часть сложности компилятора;
б) убрать проблемы VLIW со слишком ранней фиксацией порядка (одна из проблем - невозможность статического предсказания времени обращений к памяти).

Пусть процессор сам решает, что он может сейчас выполнить, а чему пока можно подождать. Команды идут одна за одной, задержка в одном потоке не стопорит другие полностью, только через зависимости, которые можно разрешить через scoreboard.

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

Есть множество систем, лучшие по любому выбранному пункту (например, декодер RISC-V - проще уже некуда, а Mill лучше по количеству IpC при более простом компиляторе).
Но все они проиграют по остальным, и даже при компромиссном одновременном улучшении по двум пунктам, они хуже моей в остальном. В целом же, КМК, такого одновременного выигрыша нет ни у кого. Пусть даже это крайне нескромная заява... Опять же, никто не мешает некоторые хорошие идеи перенести сюда - например, назначить на каждый поток свой belt на 4-8 значений с очисткой на барьерах или что-то вроде. В общем - отсюда можно копать дальше, но и так, но и уже-то очень хорошо!