Comments 36
Увидеть бы 28нм в кремнии!
TSMC - нет, SMIC - нет, AMS/XFAB/1stSilicon - нет, остаются малазийцы?
UMC?
И почему SMIC - нет?
Имеете ввиду Fab12i, которая единственная UMCшная не на Тайване и может в 28nm? Вряд ли. Хотя тут же вспомнил United Semi, которая Fab12X, проверил, там тоже есть 28nm. Так что запасной вариант есть :)
А SMIC в моей практике за месяц отказала почти полутора десяткам разным проектам на 28nm для России, включая и три китайские компании. Боятся лишиться лицензий или ждут конкретики от Партии. В общем, будем посмотреть.
Это, если отталкиваться от известного, суперскалярный процессор, который
одновременно выбирает и обрабатывает 8 команд, вдруг, по команде
программиста, превратился бы в 8 независимых скалярных процессора или в
четыре простеньких суперскаляра, каждый из которых обрабатывает 2
команды, или в два суперскаляра с параллельной обработкой 4-х команд
каждый. И не просто превратился, а продолжил бы выполнять текущие задачи
на измененной конфигурации. Ни один существующий суперскаляр этого не
может в принципе.
Multithreading? Нет, не слышал.
Из описания архитектуры я вынес, что Мультиклет не требует мьютексов. Вместо этого используется широковещательная рассылка операндов и результатов, и клетки подбирают их по необходимости.
Интересно, можно ли как-то ограничивать эту широковещательность, чтобы не хранить копии всех результатов в каждой клетке? Например, эта группа клеток делает Фурье, им нужны операнды и результаты только от забора и до обеда, а вот эта группа забирает данные из буфера Ethernet интерфейса и готовит операнды для первой группы, ей нужен доступ везде.
Многопоточность - это использование общих исполнительных блоков, например, арифметики с плавающей точкой, несколькими отдельными задачами, каждая из которых решается в своем окружении - потоке. Доступ к этим блокам может быть организован различными методами - это не суть важно. Важно, что каждый поток имеет свой набор регистров, начиная от счетчика команд и заканчивая блоком GPR. В суперскаляре каждый поток также суперскалярный, т.е. он также одновременно выбирает и обрабатывает несколько команд, у него еще также свой предсказатель переходов и т.п. Другими словами, многопоточность - это не деление суперскаляра на скаляры (как у нас деление мультиклетки на клетки), а просто существование нескольких суперскаляров в одной общей среде. Когда мы говорим о реконфигурации, то, в первую очередь, мы говорим, что это позволяет динамически из одного сложного параллельного процессора - мультиклетки, сделать несколько простых, непараллельных - для решения преимущественно последовательных задач.
Скажите, есть ли какие-то компенсирующие меры от государства, для таких частных компаний как вы, относительно санкций (что бы удержать разработчиков, перейти на другую систему комманд в процессоре, типа RISC-V)?
Насколько я понимаю, под полным запретом для производств вы не стоите, почему не пробуете заказывать и майнить сами (государство же разрешило это дело для юр. лиц., а как вы уже сказали, за 2 месяца всё отобьётся)?
Ну и, наконец, военным и космосу, сейчас нужны сбоеустойчивые процессоры, вы вроде бы намекали, что в Мультиклеточной архитектуре может быть для этого дела профит, ведётся, по этому направлению работа?
К сожалению, никаких компенсирующих мер на себе не наблюдаем (и, кстати, переход на RISK-V считаем таким же просчетом, как и базирование «отечественных» процессоров на MIPS, ARM и т.п., с такими же последствиями в близкой перспективе). Относительно майнинга и прочего - да, нас не ограничивают ничем, кроме отсутствия финансов. На всё банально не хватает каких-то 20 млн.$, так что продолжаем развивать архитектуру… Это же относится и к специзделиям, где затраты на приемку превышают разработку, а заказчик отсутствует, несмотря на большое декларируемое нам желание предприятий этих отраслей.
Если дело только в деньгах, начните коллективный сбор средств, я уверен, под майнинговое оборудование многие подпишутся. Первые процы, вроде bitfury именно так и выпускались, с нуля, причём даже не компанией а просто парой людей. И не надо ничего сверхсложного, пусть это будет какой-то блок любого формфактора подключающийся через райзер в шину.
Да, конечно, наш IDO практически на выходе, проект очень крупный. Могу посоветовать желающим участвовать в «токенизации мультиклетов» отправлять заявки на почту micron@multiclet.com, поскольку сбор может закончиться на этапе launchpad white list и в широкие массы не попадет.
переход на RISKC-V считаем таким же просчетом, как и базирование «отечественных» процессоров на MIPS, ARM и т.п., с такими же последствиями в близкой перспективе
За деревьями не видно леса?
Т.е. наличие огромного количества портированного софта, специалистов, знакомых с архитектурами вы пытаетесь выставить как негативные «последствия»?
То что вам не дают денег это потому что у вас этих «последствий» не предвидится.
Между спец акселератором на 1-2 задачи и процессором общего назначения лежит огромная пропасть.
По поводу ARM и MIPS — эта калиточка для нас, как известно, уже закрылась. Хотя MIPS, справедливости ради, не дожил до этого момента, его победил RISC-V.
Теперь по поводу RISC-V, на Хабре есть отличный обзор на эту тему. Вот фраза из этого обзора: «А компании, «исповедующие» RICS-V, догонят «армовцев» по производительности и начнут копировать лицензионную политику Arm Limited и продавать свои решения как IP-блоки через 5-7 лет.» И, если ничего не изменится, то для нас все то огромное количество софта будет просто недоступно. Как это все делается — я думаю объяснять не надо. Удивляет другое. Сколько раз мы будем получать по лбу граблями? Первый раз мы получили в шестидесятых годах прошлого века. Пока мы копировали IBM 360 (которую нам не продавали), чтобы получить то огромное количество софта, которое действительно было на этой системе, наши «партнеры» резко бежали вперед. Убежали так, что их почти не видно. И это негативные последствия этой идеологии, так как если ты заточен под использование чужого, то никогда не будешь иметь своего.
А компании, «исповедующие» RICS-V, догонят «армовцев» по производительности и начнут копировать лицензионную политику Arm Limited и продавать свои решения как IP-блоки через 5-7 лет.
В России свои разработчики ядер RISC-V.
riscv.org/member/syntacore
riscv.org/member/cloudbear
Превзойти тот уровень производительности что есть у Baikal-M1000 им вполне по силам, если будет доступ хотя бы к 28нм, конечно. Новые чипы B.E. проектировались под 6нм.
И это негативные последствия этой идеологии, так как если ты заточен под использование чужого, то никогда не будешь иметь своего.
Чужое чего? Набор инструкций это просто API. Начинка своя.
Состряпать свою наколенную RISC ISA можно за день. Ценности в этом нет никакой.
А вот разработать что-то действительно продуманное и с потенциалом расширения, то, чем будет пользоваться весь мир — это уже работа не простая. А когда это уже сделали за тебя, и софт написали, чертовски глупо этим не пользоваться.
Ещё раз замечу, что это касается процессоров общего назначения, а не специализированных ядер.
RISC-V, как и все существующие на рынке процессоры, имеет фон-неймановскую архитектуру со всеми ее проблемами. Есть такая организация, которая называется ITRS ( сейчас IRDS). Она регулярно в своих отчетах озвучивает весь спектр проблем IT технологий. В том числе и архитектурные. И, ни одна из архитектурных проблем, не решается RISC-V. Более того, и не может быть решена, поскольку эти проблемы порождены самой фон-неймановской архитектурой и без ее замены их не решить. Т.е. в научно-техническом плане RISC-V типичная тупиковая ветвь развития.
На рынке RISC-V никогда не заменит ARM, даже частично. К ARM можно относиться по разному, но надо отдать им должное, что из RISC, как из архитектуры, они выжали все и даже еще немного больше. Даже, если они где-то и отошли от RISC, то победителей не судят. Следовательно, чтобы RISC-V хотя бы догнал ARM, ему нужно пройти этот же путь. С кем он его пройдет? Сотни тысяч программистов потратили лучшие годы своей жизни на освоение, скажем мягко очень непростой, системы команд ARM и вряд ли они готовы повторить свой подвиг. И не надо говорить о предельно простых 37 командах RISC-V. Они, если RISC-V начнет решать те же задачи, которые решал ARM, очень быстро превратятся в 137 таких же сложных как и у ARM. И где найти программистов бессребреников для этого рывка?
ARM ведь не луговой цветок, который рос сам по себе. Его целенаправленно растили на грядке, которую хорошо удобряли инвестициями. Если подобные инвестиции придут в RISC-V, то неизбежно за ними придут и лицензии. Бизнес пока никто не отменял. Вряд ли ARM будет спокойно смотреть на конкурента. Что-то перекупят, что-то тихо «задушат», но в любом случае постараются вытолкать его на обочину.Софт заимствовать не получится — система команд другая. В этом плане что RISC-V, что наш Мультиклет, что своя наколенная RISC ISA сделанная за день — все едино. Системный софт придется переписывать. Прикладной — перекомпилировать. А это деньги и большие. И мы согласны, что вкладывать их надо действительно в то, что продумано и имеет потенциал расширения. В то, что по крайней мере решает часть проблем, о которых регулярно пишет ITRS (IRDS). Согласны, что работа эта далеко не простая, но только тогда есть вероятность, что этим будет действительно пользоваться весь мир. Но, это точно не RISC-V, который решает только одну задачу — не платить АРМ за лицензии. Задача актуальная, но не из списка ITRS (IRDS) и явно не для всего мира.
Не очень понятно причем здесь топонормы, если обсуждается архитектура.
Системный софт придется переписывать. Прикладной — перекомпилировать. А это деньги и большие.
ой ли. комипляторы уже есть, ядро linux'а уже есть, разные bsd тоже есть.
добавить ещё одну архитектуру в систему сборки — это, условно, прописать несколько строчек в конфигах.
Речь идет вообще-то не об этом. В этом пункте речь идет о том, какой объем работ связан с появлением новой архитектуры.
Это хорошо, что для текущей, минималистичной реализации RISC-V они сейчас есть. Но, их кто-то когда-то написал. Потратил ресурсы. И будет еще тратить. Все это надо сопровождать. Система команд RISC-V неизбежно будет меняться, если конечно авторы захотят развивать свое детище. Значит будет меняться и системный софт. И прикладной надо будет перекомпилировать, если кому-то захочется воспользоваться новыми возможностями.
Более того, и не может быть решена, поскольку эти проблемы порождены самой фон-неймановской архитектурой и без ее замены их не решить.
Т.е. в научно-техническом плане RISC-V типичная тупиковая ветвь развития.
Всё чудесатее и чудесатее.
Это конечно всё интересно, но есть более насущные проблемы, которые нужно решать — например как-то запускать существующий софт.
А применительно к нам — возможность выпускать процессоры в условиях жёстких санкций.
Что толку от ваших ITRS/IRDS?
Никакой связи с процессорными архитектурами я пока что тут не вижу.
en.wikipedia.org/wiki/International_Technology_Roadmap_for_Semiconductors
en.wikipedia.org/wiki/International_Roadmap_for_Devices_and_Systems
На рынке RISC-V никогда не заменит ARM, даже частично.
А кто говорит что он должен заменить ARM? RISC-V займёт свои ниши и будет там развиваться.
очень быстро превратятся в 137 таких же сложных как и у ARM
У ранних ARM было 26 команд :)
Опять же у ARM очень мало сложных, с аппаратной точки зрения, команд.
Системный софт придется переписывать.
Посмотрите сколько занимает аппаратно-зависимая часть в Linux.
А это деньги и большие.Это для вас деньги большие. А для RISC-V уже сделано и скачивается бесплатно прямо сейчас. Поэтому делать процы на нём имеет смысл, а на наколенной супер-архитектуре, якобы решающей все проблемы этих ваших ITRS/IRDS — нет.
Но, это точно не RISC-V, который решает только одну задачу — не платить АРМ за лицензии.
Вообще RISC-V решает другую задачу — предоставить удобную расширяемую платформу для обучения и экспериментирования.
А остальные задачи это уже следствие существования подобной платформы.
Это хорошо, что для текущей, минималистичной реализации RISC-V они сейчас есть. Но, их кто-то когда-то написал. Потратил ресурсы. И будет еще тратить. Все это надо сопровождать.
Софт и инфраструктуру для RISC-V оплачивают многомиллиардные корпорации. Разрабатываются десятки процессоров, а код пишут тысячи программистов.
Софт под Мультиклет поддерживать будете вы.
Судя по вашим заявлениям, вы как будто совсем не видите разницы?
В дополнение к предыдущему комментарию по поводу «своего и чужого».
Мы постоянно будем получать граблями, пока не поймем, чем они отличаются. Во-первых, чужое могут отобрать в любое время. Во-вторых оно нас просто деквалифицирует.
Рассмотрим ситуацию с RISC-V. Систему команд взяли готовенькой. М.б. взяли и готовый RTL код. Проект то открытый! Значит на эту тему свои мозги не напрягали. Тоже и с компиляторами. Все прекрасно, но нет работы — нет ни квалификации, ни опыта. Т.е. навык создания компиляторов или формирования системы команд утрачен, а это весьма не простое дело. Например, у Мультиклета развитие и совершенствование RTL кода потребовало несколько лет проектной работы и апробации на трех работающих кристаллах. RISC-V, насколько нам известно, у нас в стране пока апробирован только на одном кристалле, выпущенным на Микроне. Хватит этого или нет — неизвестно.
Но, вернемся к тому, что у нас своего при подобном заимствовании. Свое — только прикладная начинка. Прошло два-три года и реальные хозяева RISC-V решили вступить на путь коммерциализации проекта. Они без лишней огласки добавили в систему команд пару тройку новых команд, втихую доработали компиляторы и сказали, что теперь все это будет платное. И с чем мы остались? Со своим софтом? Да, и с отставанием на несколько лет, поскольку просто за время безмятежного существования разучились работать, а можем только стряпать на коленке свою ISA. В принципе для нас чужое может быть полезно только как временное решение. Чтобы закрывая насущную потребность выиграть время для своих проектов. Для решения реально существующих проблем к числу которых относятся проблемы сложности, тестирования, производительности. В их число входит и проблема кибербезопасности, которая решается в Мультиклете за счет того, что его система команд обладает «природной» вирусоустойчивостью. Но, к сожалению это временное становится постоянным.
Подскажите, является ли мультиклеточная архитектура неким подобием реализации идей Бабаяна (Data-flow architechture) в части параллельности: https://arccn.ru/media/babayan_video/
Или это альтернативный взгляд на ту же проблему с совсем другой реализацией?
Это не Data-flow architechture. Мы не описываем процесс выполнения операций. У нас альтернативный подход - мы описываем связи между данными.
Подробнее: Введение в мультиклеточные процессоры
Честно говоря не понимаю, прочитал ваш Whitepaper, прочитал https://en.wikipedia.org/wiki/Dataflow и не нашёл радикальных отличий. Может быть вы https://en.wikipedia.org/wiki/Flow-based_programming ?
Flow-based programming это же парадигма программирования, а не архитектура процессора, так что к нам отношения не имеет.
В основе абсолютно всех аппаратных архитектур (кроме мультиклета) лежит описание алгоритма как множества связанных данными вершин графа. В «data flow» эта связь задается явно — путем указания для каждой вершины (команды) перечня команд, которым непосредственно передаются вычисленный данной вершиной результат и в качестве какого операнда он передается. Команда выполняется, когда получит все операнды и также рассылает свой результат потребителям. В фон-неймановских машинах, связь между вершинами (командами) задается неявно — путем задания принудительного порядка их исполнения. При этом считается, что результаты ранее выполненных команд получены и доступны для всех последующих команд. Передача данных опосредована, через память.
В мультиклете для описания алгоритма используются не вершины, а дуги. Соответственно, все дуги именуются и для каждой выходной дуги указываются имена входных дуг и операция, которая должна быть выполнена. Операция выполняется, когда в общий массив результатов поступают все входные дуги. Ее результат (выходная дуга), также передается в массив результатов. Поток результатов — широковещательный. Отбор требуемых дуг осуществляется операцией, которой они необходимы.
Ну то есть в dataflow вершины явно друг другу рассылают данные, а в мультиклете вместо вершин дуги и они напрямую друг с другом не связаны, а обмениваются информацией через специальную таблицу через которую "ожидают" готовности всех необходимых входных данных?
Да, что-то вроде того.
Но ведь это по сути всё-равно подвид dataflow архитектуры. Ведь насколько я понимаю суть dataflow - это что данные диктуют порядок действий, а всё остальное - специфика устройства каждой конкретной архитектуры.
Давайте порассуждаем. Фон-неймановские процессоры часто характеризуют как процессоры, управляемые потоком команд, а так называемые потоковые процессоры, как процессоры управляемые потоком данных (data flow). Это противопоставление двух архитектурных парадигм хорошо соответствует дуальности программ (команды+данные), но является крайне неудачным их определением, так как противоречит такому базовому понятию как управление. Как известно, управление — это совокупность определенных воздействий субъекта управления на управляемый объект. Т.е. есть субъект управления - это тот, кто управляет. Есть объект управления - это тот, кем управляют. И, соответственно, есть управляющие воздействия — инструменты управления. Для начала определим, что мы будем понимать под объектом управления. Поскольку мы говорим о порядке действий, то, естественно, нас интересует каким образом формируется поток команд поступающий на исполнение. Т.е. объект управления — поток команд. В фон-неймановских процессорах поток команд жестко предопределен программой (out-of-order execution — это только на этапе исполнения) и, говорить о том, что он кем-то или чем-то управляется явно некорректно. Поэтому их можно назвать процессоры с предопределенным потоком команд. В процессорах управляемых потоком данных ситуация другая. Поток команд не предопределен. Он формируется в процессе исполнения и следовательно управляется. Вопрос в том, что является субъектом управления? В «dataflow» управляющее воздействие формирует ранее выполненная команда (это субъект), которое в виде данных (это инструмент управления) поступает очередной команде (объект). Другими словами, данные в этом варианте не кучер, а вожжи! Думается, что несколько странно говорить об управлении лошадью вожжами. При помощи вожжей — это понятно, но не вожжами, ибо непонятно, а кто такой кучер и что он делает? Если кого-то данные все таки смущают, то их из этой схемы можно легко исключить. Никто не запрещает результаты команды записать в память, а следующей команде отправить однобитовый признак готовности данных. Работать процессор будет немного дольше, но принципиально ничего не изменится. В «dataflow» субъект и объект управления совпадают — это все команды одной программы, следовательно это типичное самоуправление. Корректное определения таких процессоров — процессор с (само)управляемым потоком команд.
Теперь рассмотрим как в этой схеме выглядит мультиклеточный процессор. Выполненная команда не вырабатывает никаких управляющих воздействий, так как она не знает кто будет потребителем ее результата. Она просто раздает свой поименованный результат всем клеткам, которые записывают его в массив результатов. Обращаю внимание на то, что результат поименован. Имя — это не адрес команды и не адрес памяти. По имени, как правило, невозможно понять какая команда его сформировала. Имя позволяет разорвать непосредственную связь между командами и сформировать связь между данными (результатами). Команды, которые находятся в клетках, мониторят поток результатов и с выполняются по поступлению требуемых результатов. Т.е. их исполнение инициирует поток результатов (данных). По уму наш процессор надо было бы назвать процессор с потоком команд управляемым потоком данных или процессор с управляемым потоком данных, но к сожалению, термин «управление потоком данных» уже достаточно сильно дискредитирован бездумным использованием этого термина. Поэтому мы — Мультиклет.
Спасибо за подробное описание, для меня лично это всё-равно подвид dataflow, который может содержать радикально разные подходы, но вам видимо виднее.
Давайте уточним некоторые вопросы:
Подход Бабаяна к dataflow требует специальные языковые конструкции, спец. компилятор, запущенный рантайм компилятора для оптимизации "управляющего воздействия" на лету и конечно спец. железа. Я читал ваши статьи, вы когда-то утверждали что вам не требуется чтобы компилятор как-то по особенному упорядочивал команды. Соответственно я полагаю что вам не требуют и спец. языковые конструкции. Это до сих пор так?
Что у вас происходит, если все клетки не получили всех необходимых данных по широковещательной рассылке и находятся все одновременно в состоянии ожидания?
Подход Бабаяна к dataflow требует специальные языковые конструкции, спец. компилятор, запущенный рантайм компилятора для оптимизации "управляющего воздействия" на лету и конечно спец. железа. Я читал ваши статьи, вы когда-то утверждали что вам не требуется чтобы компилятор как-то по особенному упорядочивал команды. Соответственно я полагаю что вам не требуют и спец. языковые конструкции. Это до сих пор так?
Никаких специальных языковых конструкций нам не надо! Ни раньше, ни сейчас. Мы сейчас используем LLVM в его каноническом виде. Все, что позволяет LLVM, то доступно и нам. Требование к компилятору, в части упорядочивания команд только одно: команда выдающая результат должна стоять раньше, чем команды потребляющие этот результат. И это не противоречит фон-нейману! Разница в том, что это требование не связано с очередностью исполнения, как у фон-неймана, а связано с идентификацией команд. Т.е. инструмент один, а использование его различно.
Что у вас происходит, если все клетки не получили всех необходимых данных по широковещательной рассылке и находятся все одновременно в состоянии ожидания?
Мы просто зависаем! И это хорошо! Это аварийная ситуация, которой быть не может и которая позволяет выявить несанкционированное вмешательство, если оно произошло. У нас параграф это функциональный аналог команды в фон-неймановской машине. Как известно, вмешаться в выполнение команды мы не можем, и также вмешаться в выполнение параграфа без последствий мы тоже не можем. Представьте себе четырехадресный EDVAC, у которого адрес следующей команды доступен только на этапе компиляции. Вот это мы.
Никаких специальных языковых конструкций нам не надо! Ни раньше, ни
сейчас. Мы сейчас используем LLVM в его каноническом виде. Все, что
позволяет LLVM, то доступно и нам. Требование к компилятору, в части
упорядочивания команд только одно: команда выдающая результат должна
стоять раньше, чем команды потребляющие этот результат. И это не
противоречит фон-нейману! Разница в том, что это требование не связано с
очередностью исполнения, как у фон-неймана, а связано с идентификацией
команд. Т.е. инструмент один, а использование его различно.
ОК. Но ведь как я понимаю выбор конечного алгоритма всё-равно влияет. Ведь можно условно взять более жирный по коду алгоритм, в котором больше образуется параллельных мест при выполнении и он лучше загрузит ваши мультиклетки, но скорее всего он также лучше загрузит и superscalar и VLIW. Другой вопрос, что superscalar, что VLIW имеют низкий предел параллелизма в 4-8 и в 25 инструкций в параллель соответственно, а у вас он может быть существенно выше. Всё верно описал?
И да, может ли ваш процессор быть универсальным в теории? Т.е. нет ли для этого каких-то тяжёлых препятствий?
Интересное решение, мне почему-то мультиклетки кажутся развитием идей алгоритма Томасуло. Некоторые вещи неочевидны из статьи, поэтому спрошу:
Как происходит обработка инструкций условных переходов? Если самая первая клетка получила такую инструкцию, что происходит с инструкциями остальных, все ждут результата декодирования первой и чистятся в случае перехода?
Как осуществляется поддержка точных исключений (precise exception)?
Финальная рассылка результатов для случая большого количества клеток выглядит супертяжёлой в железе -- она либо очень медленная, либо занимает много тактов. 2ГГц указанные в тексте, это реальная частота полученная для конструкции из 64 клеток в железе или произвольное выбранное значение для симуляции?
У мультиклета был предшественник — синпьютер. Его разрабатывали в 2000-2004г.г. Команда была интернациональной: мы, датчане и шведы. Так вот швед, который курировал проект со стороны датчан (они финансировали проект) сказал две фразы, которые мы вспоминаем до сих пор. Первая — по поводу архитектуры синпьютера (когда принималось решение о финансировании): «Все по отдельности знакомое и известное, а все вместе — новое». А вторая, которую он сказал, представляя проект в 2003г. в Далласе на международной конференции по цифровой обработке сигналов : «Я представляю новую архитектуру — это не удивительно. Удивительно — то, что ее сделали русские». Тогда мы получили первый приз на форуме новых продуктов. Но, это лирика. Томасуло — это в первую очередь одна из возможных реализаций буфера для хранения выбранных команд, до момента готовности результатов. У нас тоже есть такой буфер, он выполняет эту же функцию, но устроен по другому. Вариантов подобных буферов достаточно много. Все процессоры с внеочередным исполнением команд их используют. У каждого свой. Просто буфер Томасуло самый известный. Теперь по вопросам:
Как происходит обработка инструкций условных переходов? Если самая первая клетка получила такую инструкцию, что происходит с инструкциями остальных, все ждут результата декодирования первой и чистятся в случае перехода?
Переход осуществляется, когда будет выбрана команд с признаком завершения параграфа (признак complete). Он говорит о том, что все команды текущего параграфа выбраны и можно выбирать команды следующего параграфа. Команда перехода может стоять в параграфе где угодно. Переход будет только по complete. Более того, в параграфе может быть сколь угодно много команд перехода, но адрес следующего параграфа должна вырабатывать только одна из них.
Как осуществляется поддержка точных исключений (precise exception)?
В Multiclet R1 — прерывание.
Финальная рассылка результатов для случая большого количества клеток выглядит супертяжёлой в железе -- она либо очень медленная, либо занимает много тактов. 2ГГц указанные в тексте, это реальная частота полученная для конструкции из 64 клеток в железе или произвольное выбранное значение для симуляции?
Нет такого понятия, как финальная рассылка. Есть понятия поток результатов и массив результатов. Поток результатов — это то, что вычислено в данный момент. Массив результатов — это последние 64 результата, которые, естественно, постоянно модифицируются по мере поступления новых. Замыкать 64 клетки в единую конструкцию — бессмысленно. Статистически длина жизни результат около 8 команд, т.е. в большинстве случаев он используется одной из восьми последующих команд. Поэтому 8 команд в суперскаляре за одну выборку, 8 клеток в мультиклетке. 2ГГц — это результат реального топологического проектирования для мультиклетки из 8 клеток.
Мультиклеты: влияние реконфигурации на бенчмарки и задачи майнинга