Сообщение Re[23]: Эльбрус - 8 ядер от 06.06.2017 15:39
Изменено 07.06.2017 3:17 vdimas
Re[23]: Эльбрус - 8 ядер
Здравствуйте, netch80, Вы писали:
Почитал далее — везде аналогичные заблуждения.
N>Верно. Неверно другое, невыделенное. Это не ветвление. Это неприменение результата команды.
Да какой "неприменение"? Команда тупо не исполняется и всё.
N>Ты же не считаешь, надеюсь, условное выполнение в полноразмерном ARM32 ветвлением?
1. В ARM32 есть не только условное выполнение.
2. Инструкция вида ITxxx делает от одной до 4х последующих инструкций условными, избавляя от необходимости в условных переходах, которые выполняются дольше.
3. Можно условно пропустить безусловный переход — это уже полноценное ветвление или еще нет?
N>При этом команда может частично исполниться — не в смысле видимых результатов, а в смысле подготовительных действий (например, для доступа к памяти процессор может выполнить сложение базы со смещением).
Да. Стадия fetching — одна из стадий RISC-конвейера, хотя далеко не все инструкции нуждаются в этой стадии. Но уж таковы законы жанра — в RISC длительности команд всегда фиксированы. Именно поэтому, зная, на какую тактовую частоту разрабатывается программа, можно получать тот самый true realtime, т.е. заменять RISC-процессорами железо. Мы как-то сделали возможность "допрошивки" 4-х байт в памяти программ в зависимости от точной измеренной частоты кварца конкретного экземпляра (последние кучу цифр после запятой), получая большую временнУю точность алгоритма.
V>> Безусловные ветвления отслеживаются еще на этапе предвыборки.
N>Не раньше декодирования, вообще-то.
Обсуждать подобным образом можно обсуждать только конкретные процы, а не "вообще". )
V>>Вот, опять ты недоразобрался. Речь о конвейере этих VLIW-команд, а не о нескольких командах в составе пакета. Я же написал выше — почти во всех современных RISC присутствует конвейер команд. Собсно, эта инфа даётся на первых страницах даташита процессоров, т.е. найти её легко.
N>Во-первых, там "даташиты" очень плотные (в смысле, языком, понятным только тем, кто уже в теме).
Ерунда. Просто некоторые люди терпеть не могут любую документацию.
N>Во-вторых, разные версии могут иметь разные особенности
Даташит всегда идёт на конкретную микросхему, а не на "абстрактную архитектуру".
N>Поэтому я не буду гуглить настолько вглубь (всё равно бесполезно без практического опыта), а буду таки задавать вопросы тому, кто утверждает, что он уже съел собаку на них и потоптался по граблям (так ведь?) Вопрос, собственно — что ты называешь конвейером VLIW команд?
Ну хотя бы на картинки можно было самому взглянуть? ))
N>Конвейер пакетов команд, или отдельных команд в пакете? Если второе, то означает ли это, что последующий за пакетом, в котором команда перехода, пакет может выполниться _частично_?
Нет, пакет исполняется целиком.
Другое дело, что пакет может быть не полным, т.е. в одном пакете могут быть инструкции не на все исполнительные блоки.
Собсно, задача оптимизатора в том и состоит, чтобы "поплотнее" напихать каждый пакет.
V>> И это противоречит философии RISC, когда код напрямую оперирует реально-существующими исполнительными устройствами.
N>Это в VLIW он так фигурирует. Но откуда такие выводы для RISC? Там никогда не было такой привязки.
Вот опять та же ошибка, на которую я указал пару сообщений назад — ты путаешь т.н. "архитектуру" как спецификацию системы команд и конкретную реализацию проца, совместимую с этой архитектурой.
N>"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." Против твоего проезда по количеству команд.
Наоборот, я говорю о том, что исходный термин RISC вредно пытаться расшифровывать дословно. И об этом на всех углах уже лет 20 пишут, чего сейчас-то об этом спорить? ))
Термин прижился, но давно уже означает вовсе не сокращённый набор команд, а принцип реализации процессоров. Независимо от системы команд.
N>"Этот вопрос" это какой? RISC целиком или только утверждение, что RISC несовместим с суперскалярностью? Так последнее не утверждается никак — этот вопрос обойдён. Зато в статье "Superscalar processor" явно упомянут PowerPC. Он, по-твоему, RISC, или нет?
PowerPC изначально был RISC, как и ARM.
N>Повторю вопрос выше. PowerPC — не RISC, или не суперскалярный?
Дык, назови конкретную марку микросхемы и я дам тебе точный ответ.
N>А что насчёт ARM, например, в диапазоне от Cortex-A7 (суперскалярный на 2 исполнителя) до Cortex-A17 (полный OoO)?
N>Они еретики и должны быть разрушены? Или им надо давать другое имя?
Лучше перестать, наконец, путать систему команд и реализацию совместимого с этой системой команд процессора.
Неужели после первого моего замечания не стало ясно:
Это же не бог весть как сложно... Студент 2-го курса и то уже давно был понял свой залёт.
V>>>>В общем, применение термина SIMD к суперскаляру — оно не корректно, если быть строгим. Даром внешне, т.е. сугубо для программиста, эта техника выглядит почти одинаково в обеих случаях.
N>>>Это ортогональные друг другу сущности. И "внешне для программиста" они никак не могут одинаково выглядеть. Или ты уже и SIMD переопределил по-своему?
V>>Зачем по-своему? Изначально SIMD появился в процессорах архитектуры MIPS
N>"The first use of SIMD instructions was in the vector supercomputers of the early 1970s such as the CDC Star-100
Мы еще про микропроцессоры говорим? Или уже перешли на рассыпуху и арифмометры, размером с пол-комнаты? ))
N>А в MIPS, значит, они не были "доступные для непосредственного их программирования"?
Вот там как раз были, бо RISC.
>> А в архитектуре x86 эти SIMD-команды исполняются "непонятно на чём" — на некоем черном ящике.
N>То есть если бы ставился отдельный сопроцессор в гнездо, ты бы понимал, на чём оно исполняется, а если в составе процессора, то уже нет?
Да пофик на гнёзда, я а другом говорил. В мире CISC и OoO я понятия не имею о длительности каждой команды и не могу включать эту информацию в свою программу.
Типичный цикл контроллера, который сейчас делает то, что раньше делало железо — он фиксирован. Как по-твоему, происходит фазовое детектирование того же WiFi? Ни о каких таймерах там не может быть и речи, ес-но. Там прямо в теле цикла фиксированной длительности считывается со входного порта 0/1 и происходит суммирование с отсчётами синуса и косинуса (90 градусов). 0 — отнять, 1 — прибавить. Вот тебе операция умножения входного сигнала (-1/1) на эталон. Или прецизионный контроллер управления шаговым двигателем — аналогично. Без принципиальной возможности обеспечить требуемую длительность каждой ветки алгоритма все эти вещи невозможно будет делать в софте, придётся опять возвращаться в каменный век — колхозить доп. аппаратные исполнительные блоки.
N>И в чём тогда разница этих предметных областей? Чем, по-твоему, так принципиально отличается то, что в MIPS, от SSE образца x86?
Тем, что не происходило переименования регистров, вестимо. И что программист достоверно знает, сколько там АЛУ и что там происходит.
N>Если бы ты ещё его резал иначе, чем кривым ржавым лобзиком по маршруту пьяной вороны...
Никогда не понимал вот этого настроя... Тебе вроде и поспорить охота, но и копаться в предмете спора лень.
Остаются тупые провокации в надежде, что принесут инфу на блюдечке с голубой каёмочкой. Когд я писал про "скучно" — имел ввиду именно это. Ты даже не пытаешься заинтересовать собеседника новой инфой или неожиданным взглядом на старую.
Хотя, когда-то давно, помнится, ты этими навыками обладал.
Обленился ты, кароч, по самое нимогу. ))
Почитал далее — везде аналогичные заблуждения.
N>Верно. Неверно другое, невыделенное. Это не ветвление. Это неприменение результата команды.
Да какой "неприменение"? Команда тупо не исполняется и всё.
N>Ты же не считаешь, надеюсь, условное выполнение в полноразмерном ARM32 ветвлением?
1. В ARM32 есть не только условное выполнение.
2. Инструкция вида ITxxx делает от одной до 4х последующих инструкций условными, избавляя от необходимости в условных переходах, которые выполняются дольше.
3. Можно условно пропустить безусловный переход — это уже полноценное ветвление или еще нет?
N>При этом команда может частично исполниться — не в смысле видимых результатов, а в смысле подготовительных действий (например, для доступа к памяти процессор может выполнить сложение базы со смещением).
Да. Стадия fetching — одна из стадий RISC-конвейера, хотя далеко не все инструкции нуждаются в этой стадии. Но уж таковы законы жанра — в RISC длительности команд всегда фиксированы. Именно поэтому, зная, на какую тактовую частоту разрабатывается программа, можно получать тот самый true realtime, т.е. заменять RISC-процессорами железо. Мы как-то сделали возможность "допрошивки" 4-х байт в памяти программ в зависимости от точной измеренной частоты кварца конкретного экземпляра (последние кучу цифр после запятой), получая большую временнУю точность алгоритма.
V>> Безусловные ветвления отслеживаются еще на этапе предвыборки.
N>Не раньше декодирования, вообще-то.
Обсуждать подобным образом можно обсуждать только конкретные процы, а не "вообще". )
V>>Вот, опять ты недоразобрался. Речь о конвейере этих VLIW-команд, а не о нескольких командах в составе пакета. Я же написал выше — почти во всех современных RISC присутствует конвейер команд. Собсно, эта инфа даётся на первых страницах даташита процессоров, т.е. найти её легко.
N>Во-первых, там "даташиты" очень плотные (в смысле, языком, понятным только тем, кто уже в теме).
Ерунда. Просто некоторые люди терпеть не могут любую документацию.
N>Во-вторых, разные версии могут иметь разные особенности
Даташит всегда идёт на конкретную микросхему, а не на "абстрактную архитектуру".
N>Поэтому я не буду гуглить настолько вглубь (всё равно бесполезно без практического опыта), а буду таки задавать вопросы тому, кто утверждает, что он уже съел собаку на них и потоптался по граблям (так ведь?) Вопрос, собственно — что ты называешь конвейером VLIW команд?
Ну хотя бы на картинки можно было самому взглянуть? ))
N>Конвейер пакетов команд, или отдельных команд в пакете? Если второе, то означает ли это, что последующий за пакетом, в котором команда перехода, пакет может выполниться _частично_?
Нет, пакет исполняется целиком.
Другое дело, что пакет может быть не полным, т.е. в одном пакете могут быть инструкции не на все исполнительные блоки.
Собсно, задача оптимизатора в том и состоит, чтобы "поплотнее" напихать каждый пакет.
V>> И это противоречит философии RISC, когда код напрямую оперирует реально-существующими исполнительными устройствами.
N>Это в VLIW он так фигурирует. Но откуда такие выводы для RISC? Там никогда не было такой привязки.
Вот опять та же ошибка, на которую я указал пару сообщений назад — ты путаешь т.н. "архитектуру" как спецификацию системы команд и конкретную реализацию проца, совместимую с этой архитектурой.
N>"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." Против твоего проезда по количеству команд.
Наоборот, я говорю о том, что исходный термин RISC вредно пытаться расшифровывать дословно. И об этом на всех углах уже лет 20 пишут, чего сейчас-то об этом спорить? ))
Термин прижился, но давно уже означает вовсе не сокращённый набор команд, а принцип реализации процессоров. Независимо от системы команд.
N>"Этот вопрос" это какой? RISC целиком или только утверждение, что RISC несовместим с суперскалярностью? Так последнее не утверждается никак — этот вопрос обойдён. Зато в статье "Superscalar processor" явно упомянут PowerPC. Он, по-твоему, RISC, или нет?
PowerPC изначально был RISC, как и ARM.
N>Повторю вопрос выше. PowerPC — не RISC, или не суперскалярный?
Дык, назови конкретную марку микросхемы и я дам тебе точный ответ.
N>А что насчёт ARM, например, в диапазоне от Cortex-A7 (суперскалярный на 2 исполнителя) до Cortex-A17 (полный OoO)?
N>Они еретики и должны быть разрушены? Или им надо давать другое имя?
Лучше перестать, наконец, путать систему команд и реализацию совместимого с этой системой команд процессора.
Неужели после первого моего замечания не стало ясно:
Наверно ты видел где-то реализацию OoO-процессора, совместимого с системой команд некоей RISC-архитектуры и малость недоразобрался в происходящем. Хотя, казалось бы, всё на поверхности.
Это же не бог весть как сложно... Студент 2-го курса и то уже давно был понял свой залёт.
V>>>>В общем, применение термина SIMD к суперскаляру — оно не корректно, если быть строгим. Даром внешне, т.е. сугубо для программиста, эта техника выглядит почти одинаково в обеих случаях.
N>>>Это ортогональные друг другу сущности. И "внешне для программиста" они никак не могут одинаково выглядеть. Или ты уже и SIMD переопределил по-своему?
V>>Зачем по-своему? Изначально SIMD появился в процессорах архитектуры MIPS
N>"The first use of SIMD instructions was in the vector supercomputers of the early 1970s such as the CDC Star-100
Мы еще про микропроцессоры говорим? Или уже перешли на рассыпуху и арифмометры, размером с пол-комнаты? ))
N>А в MIPS, значит, они не были "доступные для непосредственного их программирования"?
Вот там как раз были, бо RISC.
>> А в архитектуре x86 эти SIMD-команды исполняются "непонятно на чём" — на некоем черном ящике.
N>То есть если бы ставился отдельный сопроцессор в гнездо, ты бы понимал, на чём оно исполняется, а если в составе процессора, то уже нет?
Да пофик на гнёзда, я а другом говорил. В мире CISC и OoO я понятия не имею о длительности каждой команды и не могу включать эту информацию в свою программу.
Типичный цикл контроллера, который сейчас делает то, что раньше делало железо — он фиксирован. Как по-твоему, происходит фазовое детектирование того же WiFi? Ни о каких таймерах там не может быть и речи, ес-но. Там прямо в теле цикла фиксированной длительности считывается со входного порта 0/1 и происходит суммирование с отсчётами синуса и косинуса (90 градусов). 0 — отнять, 1 — прибавить. Вот тебе операция умножения входного сигнала (-1/1) на эталон. Или прецизионный контроллер управления шаговым двигателем — аналогично. Без принципиальной возможности обеспечить требуемую длительность каждой ветки алгоритма все эти вещи невозможно будет делать в софте, придётся опять возвращаться в каменный век — колхозить доп. аппаратные исполнительные блоки.
N>И в чём тогда разница этих предметных областей? Чем, по-твоему, так принципиально отличается то, что в MIPS, от SSE образца x86?
Тем, что не происходило переименования регистров, вестимо. И что программист достоверно знает, сколько там АЛУ и что там происходит.
N>Если бы ты ещё его резал иначе, чем кривым ржавым лобзиком по маршруту пьяной вороны...
Никогда не понимал вот этого настроя... Тебе вроде и поспорить охота, но и копаться в предмете спора лень.
Остаются тупые провокации в надежде, что принесут инфу на блюдечке с голубой каёмочкой. Когд я писал про "скучно" — имел ввиду именно это. Ты даже не пытаешься заинтересовать собеседника новой инфой или неожиданным взглядом на старую.
Хотя, когда-то давно, помнится, ты этими навыками обладал.
Обленился ты, кароч, по самое нимогу. ))
Re[23]: Эльбрус - 8 ядер
Здравствуйте, netch80, Вы писали:
Почитал далее — везде аналогичные заблуждения.
N>Верно. Неверно другое, невыделенное. Это не ветвление. Это неприменение результата команды.
Да какой "неприменение"? Команда тупо не исполняется и всё.
N>Ты же не считаешь, надеюсь, условное выполнение в полноразмерном ARM32 ветвлением?
1. В ARM32 есть не только условное выполнение.
2. Инструкция вида ITxxx делает от одной до 4х последующих инструкций условными, избавляя от необходимости в условных переходах, которые выполняются дольше.
3. Можно условно пропустить безусловный переход — это уже полноценное ветвление или еще нет?
N>При этом команда может частично исполниться — не в смысле видимых результатов, а в смысле подготовительных действий (например, для доступа к памяти процессор может выполнить сложение базы со смещением).
Да. Стадия fetching — одна из стадий RISC-конвейера, хотя далеко не все инструкции нуждаются в этой стадии. Но уж таковы законы жанра — в RISC длительности команд всегда фиксированы. Именно поэтому, зная, на какую тактовую частоту разрабатывается программа, можно получать тот самый true realtime, т.е. заменять RISC-процессорами железо. Мы как-то сделали возможность "допрошивки" 4-х байт в памяти программ в зависимости от точной измеренной частоты кварца конкретного экземпляра (последние кучу цифр после запятой), получая большую временнУю точность алгоритма.
V>> Безусловные ветвления отслеживаются еще на этапе предвыборки.
N>Не раньше декодирования, вообще-то.
Обсуждать подобным образом можно только конкретные процы, а не "вообще". )
V>>Вот, опять ты недоразобрался. Речь о конвейере этих VLIW-команд, а не о нескольких командах в составе пакета. Я же написал выше — почти во всех современных RISC присутствует конвейер команд. Собсно, эта инфа даётся на первых страницах даташита процессоров, т.е. найти её легко.
N>Во-первых, там "даташиты" очень плотные (в смысле, языком, понятным только тем, кто уже в теме).
Ерунда. Просто некоторые люди терпеть не могут любую документацию.
N>Во-вторых, разные версии могут иметь разные особенности
Даташит всегда идёт на конкретную микросхему, а не на "абстрактную архитектуру".
N>Поэтому я не буду гуглить настолько вглубь (всё равно бесполезно без практического опыта), а буду таки задавать вопросы тому, кто утверждает, что он уже съел собаку на них и потоптался по граблям (так ведь?) Вопрос, собственно — что ты называешь конвейером VLIW команд?
Ну хотя бы на картинки можно было самому взглянуть? ))
N>Конвейер пакетов команд, или отдельных команд в пакете? Если второе, то означает ли это, что последующий за пакетом, в котором команда перехода, пакет может выполниться _частично_?
Нет, пакет исполняется целиком.
Другое дело, что пакет может быть не полным, т.е. в одном пакете могут быть инструкции не на все исполнительные блоки.
Собсно, задача оптимизатора в том и состоит, чтобы "поплотнее" напихать каждый пакет.
V>> И это противоречит философии RISC, когда код напрямую оперирует реально-существующими исполнительными устройствами.
N>Это в VLIW он так фигурирует. Но откуда такие выводы для RISC? Там никогда не было такой привязки.
Вот опять та же ошибка, на которую я указал пару сообщений назад — ты путаешь т.н. "архитектуру" как спецификацию системы команд и конкретную реализацию проца, совместимую с этой архитектурой.
N>"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." Против твоего проезда по количеству команд.
Наоборот, я говорю о том, что исходный термин RISC вредно пытаться расшифровывать дословно. И об этом на всех углах уже лет 20 пишут, чего сейчас-то об этом спорить? ))
Термин прижился, но давно уже означает вовсе не сокращённый набор команд, а принцип реализации процессоров. Независимо от системы команд.
N>"Этот вопрос" это какой? RISC целиком или только утверждение, что RISC несовместим с суперскалярностью? Так последнее не утверждается никак — этот вопрос обойдён. Зато в статье "Superscalar processor" явно упомянут PowerPC. Он, по-твоему, RISC, или нет?
PowerPC изначально был RISC, как и ARM.
N>Повторю вопрос выше. PowerPC — не RISC, или не суперскалярный?
Дык, назови конкретную марку микросхемы и я дам тебе точный ответ.
N>А что насчёт ARM, например, в диапазоне от Cortex-A7 (суперскалярный на 2 исполнителя) до Cortex-A17 (полный OoO)?
N>Они еретики и должны быть разрушены? Или им надо давать другое имя?
Лучше перестать, наконец, путать систему команд и реализацию совместимого с этой системой команд процессора.
Неужели после первого моего замечания не стало ясно:
Это же не бог весть как сложно... Студент 2-го курса и то уже давно был понял свой залёт.
V>>>>В общем, применение термина SIMD к суперскаляру — оно не корректно, если быть строгим. Даром внешне, т.е. сугубо для программиста, эта техника выглядит почти одинаково в обеих случаях.
N>>>Это ортогональные друг другу сущности. И "внешне для программиста" они никак не могут одинаково выглядеть. Или ты уже и SIMD переопределил по-своему?
V>>Зачем по-своему? Изначально SIMD появился в процессорах архитектуры MIPS
N>"The first use of SIMD instructions was in the vector supercomputers of the early 1970s such as the CDC Star-100
Мы еще про микропроцессоры говорим? Или уже перешли на рассыпуху и арифмометры, размером с пол-комнаты? ))
N>А в MIPS, значит, они не были "доступные для непосредственного их программирования"?
Вот там как раз были, бо RISC.
>> А в архитектуре x86 эти SIMD-команды исполняются "непонятно на чём" — на некоем черном ящике.
N>То есть если бы ставился отдельный сопроцессор в гнездо, ты бы понимал, на чём оно исполняется, а если в составе процессора, то уже нет?
Да пофик на гнёзда, я а другом говорил. В мире CISC и OoO я понятия не имею о длительности каждой команды и не могу включать эту информацию в свою программу.
Типичный цикл контроллера, который сейчас делает то, что раньше делало железо — он фиксирован. Как по-твоему, происходит фазовое детектирование того же WiFi? Ни о каких таймерах там не может быть и речи, ес-но. Там прямо в теле цикла фиксированной длительности считывается со входного порта 0/1 и происходит суммирование с отсчётами синуса и косинуса (90 градусов). 0 — отнять, 1 — прибавить. Вот тебе операция умножения входного сигнала (-1/1) на эталон. Или прецизионный контроллер управления шаговым двигателем — аналогично. Без принципиальной возможности обеспечить требуемую длительность каждой ветки алгоритма все эти вещи невозможно будет делать в софте, придётся опять возвращаться в каменный век — колхозить доп. аппаратные исполнительные блоки.
N>И в чём тогда разница этих предметных областей? Чем, по-твоему, так принципиально отличается то, что в MIPS, от SSE образца x86?
Тем, что не происходило переименования регистров, вестимо. И что программист достоверно знает, сколько там АЛУ и что там происходит.
N>Если бы ты ещё его резал иначе, чем кривым ржавым лобзиком по маршруту пьяной вороны...
Никогда не понимал вот этого настроя... Тебе вроде и поспорить охота, но и копаться в предмете спора лень.
Остаются тупые провокации в надежде, что принесут инфу на блюдечке с голубой каёмочкой. Когд я писал про "скучно" — имел ввиду именно это. Ты даже не пытаешься заинтересовать собеседника новой инфой или неожиданным взглядом на старую.
Хотя, когда-то давно, помнится, ты этими навыками обладал.
Обленился ты, кароч, по самое нимогу. ))
Почитал далее — везде аналогичные заблуждения.
N>Верно. Неверно другое, невыделенное. Это не ветвление. Это неприменение результата команды.
Да какой "неприменение"? Команда тупо не исполняется и всё.
N>Ты же не считаешь, надеюсь, условное выполнение в полноразмерном ARM32 ветвлением?
1. В ARM32 есть не только условное выполнение.
2. Инструкция вида ITxxx делает от одной до 4х последующих инструкций условными, избавляя от необходимости в условных переходах, которые выполняются дольше.
3. Можно условно пропустить безусловный переход — это уже полноценное ветвление или еще нет?
N>При этом команда может частично исполниться — не в смысле видимых результатов, а в смысле подготовительных действий (например, для доступа к памяти процессор может выполнить сложение базы со смещением).
Да. Стадия fetching — одна из стадий RISC-конвейера, хотя далеко не все инструкции нуждаются в этой стадии. Но уж таковы законы жанра — в RISC длительности команд всегда фиксированы. Именно поэтому, зная, на какую тактовую частоту разрабатывается программа, можно получать тот самый true realtime, т.е. заменять RISC-процессорами железо. Мы как-то сделали возможность "допрошивки" 4-х байт в памяти программ в зависимости от точной измеренной частоты кварца конкретного экземпляра (последние кучу цифр после запятой), получая большую временнУю точность алгоритма.
V>> Безусловные ветвления отслеживаются еще на этапе предвыборки.
N>Не раньше декодирования, вообще-то.
Обсуждать подобным образом можно только конкретные процы, а не "вообще". )
V>>Вот, опять ты недоразобрался. Речь о конвейере этих VLIW-команд, а не о нескольких командах в составе пакета. Я же написал выше — почти во всех современных RISC присутствует конвейер команд. Собсно, эта инфа даётся на первых страницах даташита процессоров, т.е. найти её легко.
N>Во-первых, там "даташиты" очень плотные (в смысле, языком, понятным только тем, кто уже в теме).
Ерунда. Просто некоторые люди терпеть не могут любую документацию.
N>Во-вторых, разные версии могут иметь разные особенности
Даташит всегда идёт на конкретную микросхему, а не на "абстрактную архитектуру".
N>Поэтому я не буду гуглить настолько вглубь (всё равно бесполезно без практического опыта), а буду таки задавать вопросы тому, кто утверждает, что он уже съел собаку на них и потоптался по граблям (так ведь?) Вопрос, собственно — что ты называешь конвейером VLIW команд?
Ну хотя бы на картинки можно было самому взглянуть? ))
N>Конвейер пакетов команд, или отдельных команд в пакете? Если второе, то означает ли это, что последующий за пакетом, в котором команда перехода, пакет может выполниться _частично_?
Нет, пакет исполняется целиком.
Другое дело, что пакет может быть не полным, т.е. в одном пакете могут быть инструкции не на все исполнительные блоки.
Собсно, задача оптимизатора в том и состоит, чтобы "поплотнее" напихать каждый пакет.
V>> И это противоречит философии RISC, когда код напрямую оперирует реально-существующими исполнительными устройствами.
N>Это в VLIW он так фигурирует. Но откуда такие выводы для RISC? Там никогда не было такой привязки.
Вот опять та же ошибка, на которую я указал пару сообщений назад — ты путаешь т.н. "архитектуру" как спецификацию системы команд и конкретную реализацию проца, совместимую с этой архитектурой.
N>"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." Против твоего проезда по количеству команд.
Наоборот, я говорю о том, что исходный термин RISC вредно пытаться расшифровывать дословно. И об этом на всех углах уже лет 20 пишут, чего сейчас-то об этом спорить? ))
Термин прижился, но давно уже означает вовсе не сокращённый набор команд, а принцип реализации процессоров. Независимо от системы команд.
N>"Этот вопрос" это какой? RISC целиком или только утверждение, что RISC несовместим с суперскалярностью? Так последнее не утверждается никак — этот вопрос обойдён. Зато в статье "Superscalar processor" явно упомянут PowerPC. Он, по-твоему, RISC, или нет?
PowerPC изначально был RISC, как и ARM.
N>Повторю вопрос выше. PowerPC — не RISC, или не суперскалярный?
Дык, назови конкретную марку микросхемы и я дам тебе точный ответ.
N>А что насчёт ARM, например, в диапазоне от Cortex-A7 (суперскалярный на 2 исполнителя) до Cortex-A17 (полный OoO)?
N>Они еретики и должны быть разрушены? Или им надо давать другое имя?
Лучше перестать, наконец, путать систему команд и реализацию совместимого с этой системой команд процессора.
Неужели после первого моего замечания не стало ясно:
Наверно ты видел где-то реализацию OoO-процессора, совместимого с системой команд некоей RISC-архитектуры и малость недоразобрался в происходящем. Хотя, казалось бы, всё на поверхности.
Это же не бог весть как сложно... Студент 2-го курса и то уже давно был понял свой залёт.
V>>>>В общем, применение термина SIMD к суперскаляру — оно не корректно, если быть строгим. Даром внешне, т.е. сугубо для программиста, эта техника выглядит почти одинаково в обеих случаях.
N>>>Это ортогональные друг другу сущности. И "внешне для программиста" они никак не могут одинаково выглядеть. Или ты уже и SIMD переопределил по-своему?
V>>Зачем по-своему? Изначально SIMD появился в процессорах архитектуры MIPS
N>"The first use of SIMD instructions was in the vector supercomputers of the early 1970s such as the CDC Star-100
Мы еще про микропроцессоры говорим? Или уже перешли на рассыпуху и арифмометры, размером с пол-комнаты? ))
N>А в MIPS, значит, они не были "доступные для непосредственного их программирования"?
Вот там как раз были, бо RISC.
>> А в архитектуре x86 эти SIMD-команды исполняются "непонятно на чём" — на некоем черном ящике.
N>То есть если бы ставился отдельный сопроцессор в гнездо, ты бы понимал, на чём оно исполняется, а если в составе процессора, то уже нет?
Да пофик на гнёзда, я а другом говорил. В мире CISC и OoO я понятия не имею о длительности каждой команды и не могу включать эту информацию в свою программу.
Типичный цикл контроллера, который сейчас делает то, что раньше делало железо — он фиксирован. Как по-твоему, происходит фазовое детектирование того же WiFi? Ни о каких таймерах там не может быть и речи, ес-но. Там прямо в теле цикла фиксированной длительности считывается со входного порта 0/1 и происходит суммирование с отсчётами синуса и косинуса (90 градусов). 0 — отнять, 1 — прибавить. Вот тебе операция умножения входного сигнала (-1/1) на эталон. Или прецизионный контроллер управления шаговым двигателем — аналогично. Без принципиальной возможности обеспечить требуемую длительность каждой ветки алгоритма все эти вещи невозможно будет делать в софте, придётся опять возвращаться в каменный век — колхозить доп. аппаратные исполнительные блоки.
N>И в чём тогда разница этих предметных областей? Чем, по-твоему, так принципиально отличается то, что в MIPS, от SSE образца x86?
Тем, что не происходило переименования регистров, вестимо. И что программист достоверно знает, сколько там АЛУ и что там происходит.
N>Если бы ты ещё его резал иначе, чем кривым ржавым лобзиком по маршруту пьяной вороны...
Никогда не понимал вот этого настроя... Тебе вроде и поспорить охота, но и копаться в предмете спора лень.
Остаются тупые провокации в надежде, что принесут инфу на блюдечке с голубой каёмочкой. Когд я писал про "скучно" — имел ввиду именно это. Ты даже не пытаешься заинтересовать собеседника новой инфой или неожиданным взглядом на старую.
Хотя, когда-то давно, помнится, ты этими навыками обладал.
Обленился ты, кароч, по самое нимогу. ))