Здравствуйте, vdimas, Вы писали:

N>>Или ты не признаёшь за RISC возможность OoO (хотя это сплошь и рядом)

V>Наверно ты видел где-то реализацию OoO-процессора, совместимого с системой команд некоей RISC-архитектуры и малость недоразобрался в происходящем. Хотя, казалось бы, всё на поверхности.

V>RISC — это философия построения процессоров, хотя сама аббревиатура изначально появилась от философии формирования системы команд. Но сейчас хватает RISC-процессоров, у которых количество команд поспорит с оными из CISC-мира.

Я, извини, вцеплюсь в это "но". Если оно для тебя существенно, то тут недоразобрался явно ты, причём как раз на самой поверхности, раз такое заявляешь. Или уже всё забыл.
RISC — это не мало команд. Это _простые_ команды, которые легко поставить в конвейер, нарисовать зависимости, и так далее. Это когда у тебя нет mov @-(r2), @(r4)+, которую всё равно надо разложить на два доступа к памяти и один к регистрам, а всё надо писать отдельно.
При этом количество самих команд в ISA может быть больше любого равного по возможностям CISC (особенно это любят делать за счёт модификаторов — как в ARM изменение регистра или флажки во всяких CSINV).

А вторым уже выступает то, что есть стандартный метод упаковки команд в конвейер, который в классическом (Berkeley) исполнении — одна команда на такт, но 5 тактов на команду. Но как только начинается проблема торможения на памяти или на непредсказуемо долгих командах, там вводят полноценное OoO, ничуть не меняя общего подхода. Ни старшие ARM, ни старшие MIPS, ни Power, при всём различии их подхода, не перестают быть RISC от того, что у них OoO.

Если же "но" было несущественно, то к чему вообще этот кэпский пассаж про количество команд?

N>>или вообще что-то очень оригинальное (и слабо соответствующее действительности) думаешь про RISC. Оба варианта меня смущают.
V>Ну вот чтобы не смущало, надо отделять мух от котлет.

Вот и отделяю — и убедился, что ты опять что-то левое вспомнил.

V>>>Побочные эффекты от конвейеризированности в RISC происходят чуть в других местах — на условных ветвлениях.
N>>Не во всех RISC.
V>Почти во всех с конвейером ненулевой длины.

В новых архитектурах от delay slots отказываются, ибо польза сомнительна, а диверсионность однозначна. Даже в Alpha его уже не сделали. Фактически, он остался в тех, что разработаны более 22 лет назад (то есть совсем старьё).

N>>И откуда тут взялась идея про побочные эффекты?
V>От конвейеризированности в отсутствии планировщика, вестимо.
V>Всё-таки философия RISC — это минимизация "побочных" устройств в процессоре (помимо целевых-исполнительных).

А даже если так — транслятор в RISC занимает по-любому больше в разы, чем даже продвинутый OoO. Разумеется, если хотим, чтобы он работал быстрее одного байта за такт

V>>> Поэтому-то там бывают такие прикольные виды ветвлений, как "пропустить следующую команду".
N>>Если ты про Thumb в ARM, то это больше похоже на вариант
V>Не важно, на что это похоже. Это один из способов условного ветвления без сброса конвейера.
V>Ключевое выделено.

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

V> Безусловные ветвления отслеживаются еще на этапе предвыборки.

Не раньше декодирования, вообще-то. И безусловные переходы тоже имеют delay slots, там, где последние вообще применены.

V>>> Или, например, в той же архитектуре TI C6000 после команды ветвления будет выполнено еще +5 команд, которые уже находятся в конвейере. Т.е. эти следующие 5 команд можно забить NOP-ами, а можно заставить продолжать делать что-то полезное, что и делает оптимизирующий компилятор при компиляции тела цикла. Вот как раз в моём примере видно, что после первого ветвления еще 5 команд приносят некоторую пользу.

N>>Delay slot на 5 команд? Оригинально ты же перед этим показывал, что это VLIW. Зачем это называть конвейером, когда это пакет одновременно исполняющихся команд?
V>Вот, опять ты недоразобрался. Речь о конвейере этих VLIW-команд, а не о нескольких командах в составе пакета. Я же написал выше — почти во всех современных RISC присутствует конвейер команд. Собсно, эта инфа даётся на первых страницах даташита процессоров, т.е. найти её легко.

Во-первых, там "даташиты" очень плотные (в смысле, языком, понятным только тем, кто уже в теме). Во-вторых, разные версии могут иметь разные особенности (я не могу априорно полагать, как в x86, что код, однажды сделанный под проц 20-летней давности, будет работать).
Поэтому я не буду гуглить настолько вглубь (всё равно бесполезно без практического опыта), а буду таки задавать вопросы тому, кто утверждает, что он уже съел собаку на них и потоптался по граблям (так ведь?) Вопрос, собственно — что ты называешь конвейером VLIW команд? Конвейер пакетов команд, или отдельных команд в пакете? Если второе, то означает ли это, что последующий за пакетом, в котором команда перехода, пакет может выполниться _частично_?

V>>>Увы, конфликтует, когда речь о RISC, потому что ты понятия не имеешь, как он там устроено "унутре". ))
N>>Видимо, конфликтует только в твоих представлениях, в которых RISC не может иметь суперскалярность.
V>Не может. Еще раз, медленно. В основе суперскалярности лежит абстракция исходного кода от кол-ва исполнительных устройств. Это принципиально.

Предположим, хотя это не самая важная часть.

V> И это противоречит философии RISC, когда код напрямую оперирует реально-существующими исполнительными устройствами.

Это в VLIW он так фигурирует. Но откуда такие выводы для RISC? Там никогда не было такой привязки.

V>Помимо RISC и CISC есть еще гибридная технология со своим названием — MISC, может тебя это смущает?

"Minimal Instruction Set Computer"... как-то она не очень гибридная
Так как область очень туманная — давай ссылку на то, какой именно "MISC" ты имеешь в виду, или говорить не о чем.

N>>Или они для тебя уже не RISC? Тогда вводи свои термины специально для этой дискуссии.
V>Зачем? Есть вики, там вполне доступно и в этом вопросе правильно.

Вики — это полезно, да. Особенно когда ты на неё ссылаешься
"A common misunderstanding of the phrase "reduced instruction set computer" is the mistaken idea that instructions are simply eliminated, resulting in a smaller set of instructions." Против твоего проезда по количеству команд.
"Nowadays the branch delay slot is considered an unfortunate side effect of a particular strategy for implementing some RISC designs, and modern RISC designs generally do away with it." Против дифирамбов слотам задержек.
"Этот вопрос" это какой? RISC целиком или только утверждение, что RISC несовместим с суперскалярностью? Так последнее не утверждается никак — этот вопрос обойдён. Зато в статье "Superscalar processor" явно упомянут PowerPC. Он, по-твоему, RISC, или нет?

V>>>Суперскаляр динамически распределяет свои ресурсы, поэтому, от исходного SIMD там может ничего не остаться после отображения вот этого "абстрактного" входного бинарного кода программы на конкретный внутренний VLIW-микрокод. Ты даже не можешь гарантировать — выполнится ли эта групповая операция над данными за один такт (одновременно) или последовательно/произвольно/как получится, на доступных в данный момент вычислительных блоках. ))
N>>Спасибо, кэп. И что?
V>Дык, в этом состоит принципиальное отличие RISC от суперскаляра/СISC. Т.е. отличие не в системе команд, а в способе исполнения этих команд.

Повторю вопрос выше. PowerPC — не RISC, или не суперскалярный?
А что насчёт ARM, например, в диапазоне от Cortex-A7 (суперскалярный на 2 исполнителя) до Cortex-A17 (полный OoO)?
Они еретики и должны быть разрушены? Или им надо давать другое имя?

V>>>В общем, применение термина SIMD к суперскаляру — оно не корректно, если быть строгим. Даром внешне, т.е. сугубо для программиста, эта техника выглядит почти одинаково в обеих случаях.
N>>Это ортогональные друг другу сущности. И "внешне для программиста" они никак не могут одинаково выглядеть. Или ты уже и SIMD переопределил по-своему?
V>Зачем по-своему? Изначально SIMD появился в процессорах архитектуры MIPS

"The first use of SIMD instructions was in the vector supercomputers of the early 1970s such as the CDC Star-100 and the Texas Instruments ASC, which could operate on a "vector" of data with a single instruction. Vector processing was especially popularized by Cray in the 1970s and 1980s."

V> и имел собственную аббревиатуру. Затем в других архитектурах — DEC Alpha и PowerPC, где под векторные вычисления явным образом были введены дополнительные процессорные элементы, т.е. доступные для непосредственного их программирования. Их даже иногда называют "DSP-сопроцессоры".

А в MIPS, значит, они не были "доступные для непосредственного их программирования"?

> А в архитектуре x86 эти SIMD-команды исполняются "непонятно на чём" — на некоем черном ящике.

То есть если бы ставился отдельный сопроцессор в гнездо, ты бы понимал, на чём оно исполняется, а если в составе процессора, то уже нет?

> Т.е. как по мне — это просто стыренная из другой предметной области аббревиатура. Маркетинг, мать его так. ))

И в чём тогда разница этих предметных областей? Чем, по-твоему, так принципиально отличается то, что в MIPS, от SSE образца x86?

V>В терминологии оно как? Кто первый, того и тапки. Я просто показываю, откуда "оно" взялось.

N>>Меня интересовали не данные гугла, а твоя оценка ситуации. Ещё надеюсь на более-менее вменяемый ответ без тонн собственных терминов, совпадающих с общепринятыми по названию, но не по содержанию

V>Да, я в курсе, что иногда умею разродиться постами, "режущими слух".
V>Зрите в корень, как грится, и да пребудет с вами сила. ))

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