Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Потому можно взять даже что-то древнее типа Intel 8086 и запустить его на приличной частоте даже на FPGA. НС>На FPGA то можно логическую модель запустить, а вот если ты просто смасштабируешь готовую топологию, то вряд ли это заработает.
Основные проблемы будут с задержками памяти — 8086 не спроектирован на такую разницу в производительности CPU и памяти, какая существует сейчас. Если же сэмулировать память (кэшем на кристалле), то всё будет ОК.
Здравствуйте, Ночной Смотрящий, Вы писали: НС>Здравствуйте, Klikujiskaaan, Вы писали: K>>Ну, в топовый i9 запихали аж 18 ядер. НС>Не факт что там один кристалл.
Возможно, меня, кстати повеселил новый Ryzen 16 ядерный:
Здравствуйте, Cyberax, Вы писали:
C>Основные проблемы будут с задержками памяти — 8086 не спроектирован на такую разницу в производительности CPU и памяти, какая существует сейчас.
Здравствуйте, 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>Зрите в корень, как грится, и да пребудет с вами сила. ))
Если бы ты ещё его резал иначе, чем кривым ржавым лобзиком по маршруту пьяной вороны...
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Cyberax, Вы писали:
C>>Основные проблемы будут с задержками памяти — 8086 не спроектирован на такую разницу в производительности CPU и памяти, какая существует сейчас.
S>И как это будет проявляться?
С реальной DRAM ты его не разгонишь быстрее 20 МГц. (Насколько я помню, у 8086 на одном такте выставлялся запрос в память, а на следующем забирались или писались данные.) 20 МГц — это с расчётом на то, что 50 нс на цикл закрытия предыдущей строки и открытия следующей, у самых быстрых современных моделей. У обычных бюджетных около 70.
Всё быстрее — требует хотя бы перехода работы с памятью на асинхронный режим, то есть переделки контроллера памяти, а по цепочке — и кучи других блоков внутри.
Ну а с уровня 33-50 МГц (поздние 386, ранние 486), как известно из истории, началось активное построение кэшей памяти. (Или ещё раньше?)
Зато на статической (как тот же кэш) проблем с этим не будет. Ну подумаешь, она в 10 раз дороже...
Здравствуйте, Kesular, Вы писали:
K>А, то есть где нормальные люди используют FPGA или ASIC. Это во первых. K>А во вторых, насколько я понимаю, на Ельбрусе используется обычный линух — со всеми плюшками типа многозадачности, виртуальной памяти и так далее. И кэш там, насколько я понимаю, тоже есть. Так что откуда там вообще мог взяться hard realtime?
Hard realtime есть в виде нашлёпок на Linux. Но можно и отдельно. Имея Linux, использовать его как трамплин для построения целевой специальной ОС — банально. Лишь бы эта ОС выполняла все непрямые функции.
Кэшу он не противоречит, если в закладках по времени рассчитать вариант "кэш полностью заполнен чужим содержимым", это легко организуется в тестах.
Здравствуйте, Cyberax, Вы писали:
K>>Чем тебе не нравится VLIW и как она связана с частотой? C>VLIW требует героических подвигов со стороны компиляторов.
Дело не в компиляторах. Ситуация очень похожа на векторные инструкции. Получить от них хороший выхлоп на готовом коде редко когда удается, и используется в основном по мелочам типа зачистки памяти. Чтобы раскрыть их потенциал нужно писать специально под них код.
С VLIW все примерно так же. Обычный код вряд ли получится уложить в VLIW сильно эффективнее, чем это делают современные процессоры. Но вот если код написать специально для VLIW, то расклад будет иным.
Здравствуйте, netch80, Вы писали:
N>>>Или ты не признаёшь за RISC возможность OoO (хотя это сплошь и рядом) V>>Наверно ты видел где-то реализацию OoO-процессора, совместимого с системой команд некоей RISC-архитектуры и малость недоразобрался в происходящем. Хотя, казалось бы, всё на поверхности.
V>>RISC — это философия построения процессоров, хотя сама аббревиатура изначально появилась от философии формирования системы команд. Но сейчас хватает RISC-процессоров, у которых количество команд поспорит с оными из CISC-мира.
N>Я, извини, вцеплюсь в это "но". Если оно для тебя существенно, то тут недоразобрался явно ты
Пукнул в лужу и завилял (выделил процитированный твой кусок). ))
Мы это с тобой проходили уже.
Скучно.
N>А вторым уже выступает то, что есть стандартный метод упаковки команд в конвейер, который в классическом (Berkeley) исполнении — одна команда на такт, но 5 тактов на команду.
N>Но как только начинается проблема торможения на памяти
Не начинается. Корни RISC растут от архитектуры с фиксированным временем обращения к памяти. Т.е. время, необходимое для чтения или записи внутреннего регистра в память — фиксировано и известно. Поэтому, команды работы с памятью в RISC изначально были выделены в отдельную группу. Делается это так: выполняется команда загрузки регистра значением из памяти, потом необходимо несколько тактов выполнять NOP или другие, более полезные команды, но не касающиеся этого регистра. Вот и всё кино. Вот тебе и классика OoO, но только на уровне софта-компилятора, увы, но не железа. А уж если речь о засилье RISC в микроконтрллерах и прочих специализированных SoC, где память программ и память данных независимы и живут внутри чипа — то там совсем никаких задержек по пробращению к данным быть не может, ес-но.
N>или на непредсказуемо долгих командах
"непредсказуемо долгих" на RISC...
Я так думаю, что ты на асме всерьёз и не писал никогда. Ни под CISC ни под RISC.
Это ж мега-залёт... ))
Открой хоть раз в жизни один даташит хоть на один контроллер...
N>там вводят полноценное OoO, ничуть не меняя общего подхода. Ни старшие ARM, ни старшие MIPS, ни Power, при всём различии их подхода, не перестают быть RISC от того, что у них OoO.
Как же скучно опять...
Гуглить по "ARM is not RISC anymore".
Дальше не читал, сорри. Разбирай свою кашу сам.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, netch80, Вы писали:
V>>>Гуглить по "ARM is not RISC anymore". N>>А, ты опять в своём мире. OK.
V>Т.е. в гугле, таки, забанили. V>Так и запишем...
Подожди, что ты сейчас утверждаешь?
Что ARM — не [чистый] RISC, или что у RISC-ов не бывает out-of-order?
Первое может быть правильно, второе — скорее всего нет.
Здравствуйте, Kernighan, Вы писали:
K>Подожди, что ты сейчас утверждаешь? K>Что ARM — не [чистый] RISC, или что у RISC-ов не бывает out-of-order? K>Первое может быть правильно, второе — скорее всего нет.
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>Если бы ты ещё его резал иначе, чем кривым ржавым лобзиком по маршруту пьяной вороны...
Никогда не понимал вот этого настроя... Тебе вроде и поспорить охота, но и копаться в предмете спора лень.
Остаются тупые провокации в надежде, что принесут инфу на блюдечке с голубой каёмочкой. Когд я писал про "скучно" — имел ввиду именно это. Ты даже не пытаешься заинтересовать собеседника новой инфой или неожиданным взглядом на старую.
Хотя, когда-то давно, помнится, ты этими навыками обладал.
Обленился ты, кароч, по самое нимогу. ))
Здравствуйте, vdimas, Вы писали:
N>>"Этот вопрос" это какой? RISC целиком или только утверждение, что RISC несовместим с суперскалярностью? Так последнее не утверждается никак — этот вопрос обойдён. Зато в статье "Superscalar processor" явно упомянут PowerPC. Он, по-твоему, RISC, или нет? V>PowerPC изначально был RISC, как и ARM.
Ага. Вот я и достучался до ответа — ты считаешь, что с суперскалярностью оно уже не RISC. В то же время как общераспространённая точка зрения, что суперскалярность не отменяет RISC. Хорошо, буду считать это ответом.
V>Лучше перестать, наконец, путать систему команд и реализацию совместимого с этой системой команд процессора. V>Неужели после первого моего замечания не стало ясно: V>
V>Наверно ты видел где-то реализацию OoO-процессора, совместимого с системой команд некоей RISC-архитектуры и малость недоразобрался в происходящем. Хотя, казалось бы, всё на поверхности.
V>Это же не бог весть как сложно... Студент 2-го курса и то уже давно был понял свой залёт.
Это залёт только в твоих глазах, а я не собираюсь ставать твоим учеником (мне ещё моя психика дорога). OK, картина ясна.
N>>"The first use of SIMD instructions was in the vector supercomputers of the early 1970s such as the CDC Star-100 V>Мы еще про микропроцессоры говорим? Или уже перешли на рассыпуху и арифмометры, размером с пол-комнаты? ))
Контекст исключительно микропроцессоров в этой ветке — твоё изобретение. Так что "всё ещё" не в тему.
>>> А в архитектуре x86 эти SIMD-команды исполняются "непонятно на чём" — на некоем черном ящике. N>>То есть если бы ставился отдельный сопроцессор в гнездо, ты бы понимал, на чём оно исполняется, а если в составе процессора, то уже нет? V>Да пофик на гнёзда, я а другом говорил. В мире CISC и OoO я понятия не имею о длительности каждой команды и не могу включать эту информацию в свою программу.
Именно! И это уже камень в огород VLIW, который ты агитируешь всюду, включая мир неизбежного OoO.
V>Типичный цикл контроллера, который сейчас делает то, что раньше делало железо — он фиксирован. Как по-твоему, происходит фазовое детектирование того же WiFi? Ни о каких таймерах там не может быть и речи, ес-но.
А почему? Митра запретил сделать аппаратный накопитель тех же снятых импульсов?
Пусть готового нет, но можно FPGAʼшку запрограммировать, логика там примитивнейшая. А с таким подходом, как у тебя, можно потребовать и все шины от RS232 до ISA и USB побитно исполнять.
V> Там прямо в теле цикла фиксированной длительности считывается со входного порта 0/1 и происходит суммирование с отсчётами синуса и косинуса (90 градусов).
Я такие циклы фиксированной длительности помню из более знаменитого источника — драйвер диска для Apple II. 32 или 40 тактов на байт, в зависимости от части дорожки, циклы с NOP-PHA-PLA-etc. для выдерживания ровно нужного количества тактов 6502. И что, это хорошо?
По-моему, это всё тупой закат солнца вручную.
V> 0 — отнять, 1 — прибавить. Вот тебе операция умножения входного сигнала (-1/1) на эталон. Или прецизионный контроллер управления шаговым двигателем — аналогично.
Шаговый двигатель там тоже управлялся, было. Аж ностальгия скоро пробьёт. Зато как сейчас хорошо всей этой дурью не маяться.
V> Без принципиальной возможности обеспечить требуемую длительность каждой ветки алгоритма все эти вещи невозможно будет делать в софте, придётся опять возвращаться в каменный век — колхозить доп. аппаратные исполнительные блоки.
Наоборот, дополнительные блоки это прогресс, а не каменный век.
N>>И в чём тогда разница этих предметных областей? Чем, по-твоему, так принципиально отличается то, что в MIPS, от SSE образца x86? V>Тем, что не происходило переименования регистров, вестимо. И что программист достоверно знает, сколько там АЛУ и что там происходит.
Чем же это лучше? Если нельзя развивать архитектуру с тем, чтобы не переписывать код?
N>>Если бы ты ещё его резал иначе, чем кривым ржавым лобзиком по маршруту пьяной вороны... V>Никогда не понимал вот этого настроя... Тебе вроде и поспорить охота, но и копаться в предмете спора лень.
В случае RISC, мне не лень (пока что; станет лень — просто перестану отвечать). Мне очень не лень, потому что ищу сказанные совершенно побочные, но ценные для будущих раскопок слова.
В случае VLIW, мне интересно содержимое, но пока что очень абстрактно (не думаю, что придётся этим заняться в ближайшие годы — ни в виде IA64, ни в виде этих DSP). Потому я его сильно не касаюсь, только в пределах предыдущих зацепленных в споре вопросов. Формат позволяет понять, в какую сторону уже серьёзно гуглить.
V>Остаются тупые провокации в надежде, что принесут инфу на блюдечке с голубой каёмочкой. Когд я писал про "скучно" — имел ввиду именно это. Ты даже не пытаешься заинтересовать собеседника новой инфой или неожиданным взглядом на старую.
Во-первых, здесь немного не тот профиль, чтобы именно "заинтересовать". Местные дискуссии — я к ним стараюсь подойти предельно конструктивно, но они всё равно больше рассчитаны на поиск слабых точек для выяснения под собственные интересы. Если тебе неинтересно — ты мог банально не участвовать.
Во-вторых, я совершенно не представляю себе, чем именно тебя можно ещё заинтересовать — твои вихревые процессы непредсказуемы настолько, что максимум того, что можно делать — это отклонять отдельные потоки Ты же делаешь вид, что всё всегда знаешь
V>Хотя, когда-то давно, помнится, ты этими навыками обладал. V>Обленился ты, кароч, по самое нимогу. ))
Я ли изменился, или кто-то другой?
The God is real, unless declared integer.
Re[2]: Подскажите как сейчас принято искать работу
Здравствуйте, vdimas, Вы писали:
V>Не факт, что в военных комплексах будет использоваться Linux, а не какая-нить реалтаймовая ось или даже вовсе без всякой ОС. В крайнем случае есть разновидности реалтаймового Linux.
Когда перепрыгнут, тогда и будешь говорить гоп. А пока это всего лишь фантазии.
V>Т.е. пруфов нет. Так и запишем.
Здравствуйте, netch80, Вы писали:
N>Hard realtime есть в виде нашлёпок на Linux. Но можно и отдельно. Имея Linux, использовать его как трамплин для построения целевой специальной ОС — банально. Лишь бы эта ОС выполняла все непрямые функции.
Hard realtime вообще невозможен, когда исполнение может замерзнуть на сотню-тысячу тактов в произвольный момент времени из-за планировщика задач, промаха кэша или memory barrier.
N>Кэшу он не противоречит, если в закладках по времени рассчитать вариант "кэш полностью заполнен чужим содержимым"
А, ну-ну. Тогда и на винде можно делать очень даже Hard realtime, если записать в спеке, что любая операция должна выполняться не более секунды.
Здравствуйте, Kesular, Вы писали:
N>>Hard realtime есть в виде нашлёпок на Linux. Но можно и отдельно. Имея Linux, использовать его как трамплин для построения целевой специальной ОС — банально. Лишь бы эта ОС выполняла все непрямые функции. K>Hard realtime вообще невозможен, когда исполнение может замерзнуть на сотню-тысячу тактов в произвольный момент времени из-за планировщика задач, промаха кэша или memory barrier.
Hard realtime всего лишь говорит, что изделие ни при каких условиях не должно отработать реакцию на событие дольше, чем установленное время, иначе оно неработоспособно и не подлежит эксплуатации. Хоть десять тысяч тактов, хоть миллиард.
Есть ещё firm realtime (не успели => выкинули один результат, качество открыто ухудшилось, но система считается рабочей) и soft (обеспечиваем в среднем по больнице). Бывают комбинированные (soft для среднего, но firm или hard для максимума).
С другой стороны, само построение системы так, что в ней есть проблемы подобного рода, заставляет думать в духе "ну мы вроде гарантировали, что оно не более 21 раза замёрзнет на 200 тактов, но где гарантия, что их вдруг не будет не 21, а 42?" — и тогда начинают таки думать про системы, где SRAM, а не DRAM+кэш, барьеры памяти не нужны, а планировщик занят только background-задачами, а всем остальным немедленно уступает место (и ещё пачка вкусностей, например, автосвитчинг банка регистров).
N>>Кэшу он не противоречит, если в закладках по времени рассчитать вариант "кэш полностью заполнен чужим содержимым"
K>А, ну-ну. Тогда и на винде можно делать очень даже Hard realtime, если записать в спеке, что любая операция должна выполняться не более секунды.
Первая часть — про то, что hard realtime может быть при условии "не более секунды" — абсолютно верна. Это всего лишь hard realtime с необычно высоким временем реакции.
Вторая — что на винде можно его делать — очень сомнительна, учитывая, например, пачку недавних историй с Windows 10 с неплановыми перезагрузками. Впрочем, я и на более ранних видел ситуации типа "задумалась на несколько секунд ХЗ почему".
Здравствуйте, vdimas, Вы писали:
V>Типичный цикл контроллера, который сейчас делает то, что раньше делало железо — он фиксирован. Как по-твоему, происходит фазовое детектирование того же WiFi? Ни о каких таймерах там не может быть и речи, ес-но. Там прямо в теле цикла фиксированной длительности считывается со входного порта 0/1 и происходит суммирование с отсчётами синуса и косинуса (90 градусов). 0 — отнять, 1 — прибавить. Вот тебе операция умножения входного сигнала (-1/1) на эталон. Или прецизионный контроллер управления шаговым двигателем — аналогично. Без принципиальной возможности обеспечить требуемую длительность каждой ветки алгоритма все эти вещи невозможно будет делать в софте, придётся опять возвращаться в каменный век — колхозить доп. аппаратные исполнительные блоки.
А можно чуть по-подробнее, что не так с таймерами, в случае с шаговым двигателем?
