Comments 207
Как апологет движения open source, open hardware и RISC-V в частности, вставлю свои незамысловатые пять копеек.
Открытая и расширяемая система команд это очень замечательно. Еще более замечательно если эта система команд является хорошо выверенно, лишенной атавизмов и избыточности (ортогональной), нацеленной на решение современных задачи, как-то векторные, матричные и нейро вычисления. Но! Какой бы эффективной ни была система команд микропроцессора, это всего лишь 5% (если не меньше) в его производительности. Гигантский пласт решений, которые делают современные микропроцессоры от AMD и Intel столь непревзойденно эффективными, скрывается в микроархитектуре - в тех самых многоуровневых схемах из вентилей и триггеров которые реализуют систему комманд в виде супескалярных OoO конвейеров, высокопроизводительных кэшей, интерконнекта и т.д. И почти все эти микроархитектурные решения являются глубоко проприетарными: закрытыми лиценциями, защищенными авторским правом и NDA, и часто просто являются коммерческой тайной не подлежащей передаче кому либо. Получается, что молодым микропроцессорным компаниям почти закрыт путь к созданию высокоэффективных вычислительных ядер, так как ни Intel, ни AMD, ни ARM, ни IBM и ни Apple не ходят лицензировать свои микроархитектурные решения дабы не плодить конкуренцию (ARM делает это но за огромные деньги и с условием применять только их ISA). Путь у таких компаний один - создавать свои микроархитектурные решения, а это катастрофически сложно, долго, с большим количеством проб и ошибок и, как следствие, является финансово неподьемным. А еще в этом деле можно легко нарваться на судебные тяжбы с тем же Intel-ом или IBM за случайное повторение уже запатентованных решений. Именно поэтому мы сейчас не видим на рынке высокоэффектиных вычислительных ядер на базе RISC-V, и, скорее всего, еще не скоро их увидим.
Нет никаких технических препятствий для того, чтобы реализовать высокопроизводительный микроппроцессор с микроархитектурой типа Skylake, Alder Lake или Zen 5, но с программным интерфейсом (т.е. системой команд) RISC-V. Однакож ни Intel, ни AMD не проявили ни малейшего интереса в этом направлении. Почему ? Да потому, что выпустив такой микропроцессор они вскроют ящик пандоры. Сейчас очень удобно, через разного рода эксперов, потихонечку поливать RISC-V всякими субстанциями, ведя рассказы в духе "RISC-V еще сырая, еще молодая, вот пусть окрепнет... а вот x86 и arm - надежный старый конь". Но действительность такова, что никто из топовых производителей микропроцессоров не желает выпускать такие продукты, для них это страшный сон. Но есть надежда. Надежда на то, что у Intel-а дела не пойдут, а покатятся вниз по касательной и тогда они будут вынужены пойти на радикальный шаг дабы вдохнуть новую жизнь в свою продукцию, и может быть тогда нас ждет новая эра.
В RISC-V International страшно увлеклись расширениями. Этих расширений уже наплодили столько, что если выпустить микропроцессор поддерживающий хотя бы половину этих расширений, то число поддеживаемых им инструкций превысит самый топовый камень от Intel со всеми его архаизмами. И это еще не всё. Заложенная в RISC-V возможность кастомизации приводит к тому, что начали появляться микропроцессоры с системой команд с "вариацией на тему". Всё это не прибавляет универсальности и совместимости. Я просто уверен, что вместо одной единой системы команд, мы придем к нескольким десяткам вариантов полность или частично несовместимых между собой вариантов RISC-V. Маслица в огонь подольют (и уже подливают) национальные варианции. И несмотря на наличие компиляторов и решений автоматизирующих перенос кода с одной системы команд на другую, жизнь программистов станет сущим адом. Короче, нас ждет балканизация системы команд микропроцессоров.
Однако ж ни Intel, ни AMD не проявили ни малейшего интереса в этом направлении. Почему ?
Потому что для этих компаний наличие огромной программной экосистемы x86 и монополия на эту архитектуру является колоссальным конкурентным преимуществом. Поэтому для Intel/Amd нет никакого смысла делать RISC-V чипы в тех сегментах, где они доминируют.
Именно так. Как только Intel выпустит высокопроизводительный проц с RISC-V архитектуруй, тут же настанет конец x86 и её монопольному положению на рынке, а этого в Intel позволить сейчас не могут. Но может случитсья так, что накал страстей всё развернет на 180 градусов.
И всё легаси моментально переедет на RISC V? x86 - странная и ужасная архитектура, но поддержка работы старых бинарников - однозначный плюс.
Помнится Itanium64 не взлетел из-за отказа от x86, а AMD64 взлетел благодаря поддержке x86.
Так что RISC V - это для Andriod и Apple.
А так же для Linux, BSD — одним словом, для систем, где не трясутся над бинарной совместимостью, потому что или исходники открыты и можно легко пересобрать, или достаточно воли чтобы продвинуть решение.
Ну пересоберите PHP 8 с поддержкой JIT на RISC V )
Как напишут JIT на RISC V для PHP 8 — так сразу =)
Так это написание JIT и входит в данном случае в портирование на новую архитектуру. Как и, скажем, для Java или Chromium (там вроде поддержка RISC V есть, но возможно качество генерируемого кода ещё тюнить придётся).
Но уж точно не входит в "поддержку работы старых бинарников"
Собственно, эта "поддержка работы старых бинарников" автоматически позволяет пользоваться тем же JIT на новых процессорах Intel/AMD.
POPCNT последнее время сломала много копий
Нет, не позволяет. Интел уделяет монументальное количество времени и средств на адаптацию библиотек к своим постоянно меняющимся процессорам, выжимая максимум из новых инструкций и обеспечивая эту самую "бинарную совместимость" на уровне библиотек. Всё это скрыто под капотом и обычно пользователю не заметно. Так же срыто от пользователя и то, что огромный пласт проблем совместимости решается на уровне операционной системы (новая Винда всегда выходит чуть раньше нового интеллового проца и это не просто так). Но если Вы возмёте какой-то старый софт (10-15 летней давности), старую ОС и попытаетесь запускать всё это на новых процах, то в лучшем случае Вас ждет очень посредственная производительность, а в большинстве случаев Вы столкнетесь с массой проблем с запуском ПО и его стабильной работой.
и обеспечивая эту самую "бинарную совместимость" на уровне библиотек.
Можно конкретный пример отсутствия обратной совместимости на уровне инструкций процессора?
Попробуйте установить Windows XP на современный интелловый проц. Вы столкнетесь с огроменным количеством проблем совместимости, в том числе и на уровне системы команд.
Мне как-то попадалась статья одного хакера которому это удалось, но ему пришлось надергать кусочков из Windows 10, в итоге получился гибрид ежа и ужа.
на 8-9 поколение вполне можно хоть NT4 установить, а это в общем вполне еще бодрые процессоры
Конкретную проблемную команду процессора всё таки назовите. Проблемы с совместимостью будут в основном из за обвязки - чипсет, BIOS (который теперь UEFI) и т.п.
Я попытаюсь найти эту статью и дам Вам на изучение, там проблемы по всем направлениям. И да, современный микропроцессор это не только система команд. Даже если Intel и поддерживает все древние инструкции, за последние 10 лет они навводили столько всякого говна в свои микропроыессоры, что запустить на них старый софт просто невозможно.
Я регулярно запускаю софт 10-15 летней и более давности на новых процах. Никакой разницы разумеется же нет. Вот прям сейчас запущен тотал коммандер 2005 года. Работает.
обеспечивая эту самую "бинарную совместимость" на уровне библиотек
Спасибо, поржал.
Гугл сходу выдает LLVM KaleidoscopeJIT. Так что, возможно, это просто вопрос интеграции инструмента vs костылесипединга
LLVM плохо применим к динамическим языкам (иначе бы и в браузерах, и в PHP движках давно сидели бы на нём). В Java теоретически запользовать можно, но там много усилий потрачено на дополнительную оптимизацию по результатам профилировки непосредственно в процессе исполнения и переехать на LLVM с их сохранением несколько нетривиально.
Это было 20+ лет назад. Тогда тоже были альтернативные платформы - MIPS, Sparc - но сборка ПО под них была сильно опциональной. Сейчас даже какие-то пользовательские утилиты и под x86, и под ARM пилят.
за отказа от x86
Не совсем так.х86 был,но работал слишком медленно,обычный пентиум был быстрее на этой же частоте.В последующей серии Интел отказался от аппаратной трансляции и перешёл на софтовую эмуляцию.Она даже на некоторых задачах работала вполне сносно.Но время было упущенное и самое главное - оказалась что смесь обычного процессора с dsp или видеокартой проще программировать и у них даже лучше с наращиванием производительности.Единственно где покупка этого процессора оправдалась -суперкомпьютер для исследования генома (закрыли 2 года назад).
Мир бинарной совместимости потихоньку уходит в прошлое. Опенсорс и компиляция по месту (JIT) приходит на смену. Если Интел или AMD продолжать цепляться за бинарную совместимость, то они рискуют в один момент остаться за бортом.
И какие AAA игрушки нынче распространяются в исходниках или JIT компилируются? На серверах - да, в основном open source и JIT (хотя, скажем, SAP или Oracle пока не умерли), но JIT движок под новую платформу сам собой не появится и не всегда можно просто запользовать LLVM. Так что в принципе смена архитектуры сейчас действительно реальна, но требует определённых усилий. При этом ARM в плане внедрения в десктопы и суровый энтерпрайз уже заметно продвинулся, у RISC V ещё всё впереди.
у RISC V ещё всё впереди.
Тут есть интересный нюанс: ARM, протаптывая дорогу к портабельному софту, делает это в том числе и для RISC-V - разработчики учатся писать совместимый софт, появился принципиально новый портабельный компилятор (LLVM) и все это идет в общую копилку. Никзкоуровневая аппаратная зависимость давно уже стала уделом разработчиков компиляторов и операционых систем, а весь пользовательский софт давно портабелен (за исключением некоторых клинических случаев) и независим не только от ISA, но и от операционных систем. Это касается как оперсор, так и проприетарного коммерческого софта.
ARM, протаптывая дорогу к портабельному софту, делает это в том числе и для RISC-V
Нет, арм продирается сквозь кусты вслед за интел, и все больше подражает последнему что бы было легче.
разработчики учатся писать совместимый софт
С оптимизациями по NEON и SVE ) Возможно, искажённая картина мира, но вижу, как вокруг оптимизируют прикладной софт на интринсиках, а то и с самописным JITом. Переносимая векторизация - пока ещё скорее светлое будущее, хотя подвижки в эту сторону есть.
AAA игрушки внутри очень портабельны, выпуск под еще одну платформу - это установка еще одной галочки в настройках проекта и все. Так что никого они на x86 не удержат. Их перевыпустят сразу и все. Особенно сейчас, когда там все интересное все равно делается на SPIR.
x86 держится не на игрушках, а на большом количестве узкоспециализированных приложений, которые поддерживаются кое-как и которые некому портировать. Местами там даже на Delphi есть. Самый ад - в софте для всяких узкоспециализированных железок. Тот же "умный дом" на KNX настраивается строго одной софтиной от строго одного вендора, работающей строго под виндой, требующей аппаратный ключ в USB и с жутким legacy внутри. С учетом того, что я видел, кто и как ее пишет, быстро ее никуда и ни на что не портируют. Ее даже просто другим компилятором под ту же винду пересобрать не получится.
Это именно то, что случилось когда интел выпустил итаниум. настал конец их монопольному положению, хорошо что тогда они это могли себе позволить.
Программный интерфейс это случайно не аналог fpga в центре процессора?
Однакож ни Intel, ни AMD не проявили ни малейшего интереса в этом направлении. Почему?
А почему они должны это делать? Вот честно, пытался прикинуть и ни одной заметной причины не смог придумать. Сюрприз, но AMD и Intel это коммерческие компании и они делают продукт не для удовлетворения любопытства, а для продажи (кто знает, может в рамках R&D у них в лабораториях и есть образцы, но мы же про массовый продукт?). Кто будет массовым покупателем для этих процессоров - я даже придумать не могу. Домашний сегмент - сразу мимо, серверный - у интела уже был опыт с потрясающе эффективными итаниумами. Не представляю, как можно будет продавить эту авантюру еще раз. Тот же ARM в серверах вроде понемножку что-то делает, но никакого взрывного роста не наблюдается, а значит вопрос энергоэффективности не так уж и остр по сравнению с другими (а они есть). Офисники.. Ну посмотрим опять же на пример Qualcomm попытавшегося влезть на полянку ноутбуков, но чисто имхо, пока тоже не вглядит прорывным продуктом. Я про него после выпуска и тестов первых дней вообще ничего не слышу в общем поле.
Ну и глобально, зачем пытаться делать конкурента своим же продуктам - решительно неясно. Риски, даже очевидные, заметны сразу, а преимущества, мягко говоря неочевидны, особенно в обозримой перспективе.
Так то RISC это не малое количество инструкций, вон тот же AVR вполне себе RISC, а там инструкций больше сотни. Это процессор с простыми инструкциями. Ну и большое число РОН очевидно.
Если не ошибаюсь, то сам Паттерсон и ввел такое понятие как "ортогональная система команд". Это такой набор команд, который не содержит избыточности в рамках какого-то класса задач. С точки зрения разработчиков AVR, их система команд содержит минимально достаточной набор команд для своего класса.
Проблема в том, что решаемые классы задач постояно меняются. С появлением "мультимедия" набор инструкций резко стал разбухать: сначала векторыми 128, потом 256 и 512, а теперь вот матричными и всякой нейрохренью. На мой взгляд все эти специфические инструкции нужно вынести из системы команд процессора общего назначения и имплементировать их в виде отдельной аппаратуры через стандартные периферийные интерфейсы (либо на всё том же кристалле, для быстроты, либо на отдельном). Зачем весь этот багаж интегрируют прямо в систему команд мне не понятно. Ведь эти специфические инструкции используются оганиченным числом приложений и, по сути, висят они там без дела. В то же время они создают массу проблем для операционной системы, увеличивают площадь и сложность декодера, и уменьшают пропускную способность конвейера (ограничивают предел тактовой частоты). Выкинуть их нафиг, оставить только RV64GC и на этом успокоиться. Кому надо - пусть делают ядра ускорителей в духе Nvidia или AMDGPU. Это позволило бы существенно поднять тактовую частоту и увеличить число ядер на кристалле, что для большинства задач является более важным, чем считать нейронки и 3D графику.
Не путайте апи к некоему черному ящику и инструкции, позволяющие этот ящик реализовать.
Необходимы оба.
На мой взгляд все эти специфические инструкции нужно вынести из системы команд процессора общего назначения и имплементировать их в виде отдельной аппаратуры через стандартные периферийные интерфейсы (либо на всё том же кристалле, для быстроты, либо на отдельном).
В RISC-V именно так и предлагается делать
Кем предлагается ? Пока что я вижу как пухнет система команд от всё новых и новых расширений. Не то, чтобы они плохие или бесполезные, просто совать их в систему команд процессора не следовало бы. И я не смог найти внятного обьяснения почему консорциум RISC-V International выбрал именно такой подход.
пухнет система команд от всё новых и новых расширений.
Так это именно расширения, никто не мешает реализовать только RV32I. А если нужна акселерация - то лезть по каждому мелкому чиху к отдельному IP (даже на том же чипе) может быть дороговато. Одно дело заоффлоадить декодирование видео, другое - скажем, вычисление crc где-нибудь в потрохах ядра.
Где-то интел анонсировала новую упрощённую архитектуру, частично совместимую с x86-64 и процессоры сразу запускаются в режиме 64 бит? Ничего свежего не слышно?
RISC = Reduced Instruction Set Architecture. Изначальная идея была именно в уменьшении и упрощении системы команд и, за счёт этого, упрощении компилятора. Именно, упомянутые в статье граждане первые додумались, что пользователь пользуется не процессором, а программно-аппаратным комплексом. И успешно улучшили весь комплекс за счёт упрощения системы команд.
Но, по скольку, с одной стороны, в интеле тоже не дураки сидят (сидели, во всяком случае), а с другой, нужны определённые фичи, то со временем по количеству команд (и по многим другим показателям) произошла конвергенция. И сегодня количество команд armv8 и x86_64 примерно совпадает.
Изначально идея была в том, чтобы убрать микрокод как класс и через ISA дать прямой интерфейс к возможностям процессора без этой прослойки. Усложнение ISA из-за дополнительной функциональности в ALU и прочих юнитах процессора идее RISC не противоречит.
Если уж на то пошло, то граница идёт по системе команд процессора, которая видна программистам.
А микрокод там внутри на декодере вычислительного ядра или аппаратная реализация команд — это дело архитектуры кремния. Туда только разработчиков процессора допускают. И снаружи никакой разницы нет.
Идея скорее в обратном, в повышении сложности и удобства в командах отдавать на уровень промежуточных языков, виртуальных машин и компиляторов. А процессору отдавать максимально удобный машкод для проектирования максимального аппаратного перфа. Это я пересказывают вводные по риск5 от Паттерсона :)
Это я пересказывают вводные по риск5 от Паттерсона :)
А оригинальную статью 1980го года про RISC читали?
А есть кто-то в теме и не читавший эту статью? :)
Но отсылка была на «Атлас RISC-V» и основные спеки риск5, в которые материалы из атласа перекочевали в виде примечаний и объяснений тех или иных принятых решений.
Причём Атлас был практически сразу переведён и издан на испанском и китайском, а китайски даже вышел бесплатной книгой. На русском его так и не было, что очень жаль — много вопросов по системам команд снимает и даёт почву для совершенствования современных представлений о том, куда развивается процессорная архитектура.
У меня есть пара книг за его авторством, в том числе сборник статей "Электроника СБИС. Проектирование микроструктур" от 1989г, Мир. И из их прочтения у меня сложилось обратное представлени - Паттерсон в молодости поработав на запуске мэйнфреймов четко решил избавляться от микрокода. :)
Только, надо дополнить, не Reduced Instruction Set, а (Reduced Instruction) Set
Не урезанный набор инструкций, а набор упрощенных инструкций, что естественным образом приводит к упрощению и уменьшению самого набора, но при этом никак не мешает расширять его.
Так же и CISC — это набор сложных инструкций (выполняющих сразу комплекс операций под капотом).
То у многих, почему-то, происходит фиксация на Instruction Set как на неделимой сучности.
В Стендфорде, где это всё придумали, с вами не согласны
RISC, or Reduced Instruction Set Computer. is a type of microprocessor architecture that utilizes a small, highly-optimized set of instructions, rather than a more specialized set of instructions often found in other types of architectures.
Да и в самой статье упоминается первый риск:
В итоге появился экспериментальный процессор RISC-I (44 420 транзисторов) с упрощённым набором команд (32 инструкции)
что естественным образом приводит к упрощению и уменьшению самого набора
Кто с чем несогласен?
Наоборот, прямое подтверждение.
Вы утверждаете что Reduced в RISC относится к Instruction, а не к Set. То есть по-вашему, по-русски правильно, "набор упрощённых инструкций". Тогда как из вышеприведённых цитат очевидно, что верно традиционное понимание: "упрощённый набор инструкций"
из вышеприведённых цитат очевидно
прямое калькирование и отсутствие семантической группировки вообще.
Не говоря уже о том, что приводить особенности устоявшегося перевода в качестве аргумента столь же верно, сколь называть взаимодействие с GUI — ксерить.
Речь о причинноследственной связи. И то утверждение можно фальсифицировать.
"ARM сломала обе ноги" Я так и не нашел пояснения этого в тексте.
Arm сильно зависит от тех процесса. Она не сломала ноги, но уже уперлась в потолок - дальнейшее увеличение её потенциала сильно зависит от уменьшения тех процесса, либо увеличения площади кристалла + все это дело нуждается в хорошем охлаждении. Вот собственно потому и в телефонах частоты камней едва превышают 2 ГГц. Боюсь, рассказы про эффективные плоские испарительные камеры в очень плоских гаджетах, без активного охлаждения - не более чем маркетинговый ход.
Вот собственно потому и в телефонах частоты камней едва превышают 2 ГГц.
Но в серверных решениях на ARM подобного ограничения нету, в силу наличия нормальной, активной системы охлаждения.
Да и засимость от уменьшения техпроцесса с увеличением площади кристалла, касается вообще всех.
Так это касаетс вообще всех архитектур и x86 и RISC-V и даже Эльбруса.
Arm сильно зависит от тех процесса.
Любой высокопроизводительный ОоО процессор зависит от тех процесса.
ARM, x86 или RISC-V - это просто разный программный инструмент к более-менее одинаковому ядру.
Вот собственно потому и в телефонах частоты камней едва превышают 2 ГГц
Уже превышают 4ГГц (iPhone 16)
ARM несколько упёрся в потолок, тогда как у х86 потенциал ещё раскрывать и раскрывать.
Макбук на M4 хотя бы догоните в однопотоке =)
Так snapdragon новый же вроде как его уел, не? Не вижу смысла выколупывать циферки - все процы по своему хороши. Арм просто холоднее и экономичнее. Амд и интел вроде как уже собираются объединить усилия в х86 архитектуре, из-за того что арм начинает значительно доминировать на рынке, что даже уже на десктопы пришёл. А риск-5 - это по факту архитектура будущего, но пока её не приведут к единым стандартам - в массовый рынок она не попадёт, хотя потенциал внушительный. Не факт, что на нашем веку увидим, хотя все может быть.
Амд и интел вроде как уже собираются объединить усилия в х86 архитектуре
Ну может вместе таки раскроют потенциал )
У амд, по-моему мнению, все в порядке с архитектурой - они заранее проработали направление, а вот интел в прошлом сократила инженеров и увеличила штат мракетологов, предлагая старые технологии по новыми моделями из года в год, что и привело к её плачевному состоянию, что арм теперь её поглотить готова. Сложно сказать чем все это теперь закончится. Но, как по мне, сюжет тянет если не на блокбастер, то на весьма содержательный сериал.
Лучше бы раскрыли risc-ядро альтернативным набором команд )
*программный инструмент -> программный интерфейс
Так snapdragon новый же вроде как его уел, не?
Кого, M4? X-E и рядом не лежал.
X-Elite очень сильно задержался, потому что ядро Phoenix делалось под сервер, потом Qualcomm купил разработчика и ядро переделывали под смартфон/ноут -> Oryon.
Потом была судебная тяжба с ARM, которая существование проекта X-E поставила под вопрос.
По-сути Oryon был сделан по перф-таргетам 2020г. Пройдёт ещё 1-2 поколения со спорными результатами, прежде чем они смогут компенсировать отставание.
Только Apple не сидит сложа голову.
Арм просто холоднее и экономичнее.
Архитектура влияет на последние 5% (условно). Остальные 95% это микроархитектурная работа, которая по большей части одинакова для разных архитектур.
А риск-5 - это по факту архитектура будущего
Определённо нет. Это академическая архитектура, со своими костылями.
R5 это лоскутное одеяло и какое-либо отсутствие вменяемой стандартизации,
что мешает созданию стандартных дистрибутивов и понятной и устойчивой программной инфраструктуры.
Идеологически они сейчас там, где ARM был в начале нулевых.
Шикарная статья! Спасибо, Автор! Хоть я довольно поверхностно разбираюсь в архитектурах, прочёл залпом) потенциал RISC-V действительно велик и, надеюсь, он себя раскроет.
Система команд без флагов не нужна.
Вам недостаточо флагов в CSR ?
Если Вы про флаги для операций АЛУ, то такие флаги усиливают зависимости команд между собой и усложняют декодер, что являет пролемой при реализации конвейера с внеочередным исполнением.
то такие флаги усиливают зависимости команд между собой
Точно? Учитывая, что уже давно отдельные биты отслеживаются независимо.
Я же не говорил, что решений нет. Есть масса способов разрешения зависимостей как внутри одного конвейера, так и между разными в пределах одного ядра (старый добрый Томасуло). Но как писал Паттерсон, избавившись от флагов мы сильно упрощаем работу микроархитектурным разработчикам, декодер получается проще, потребляет меньше места (и электричества) и позовляет повысить тактовую частоту.
Флаги нужны для наращивания разрядности арифметики, проверки переполнений и всё такое. Без флагов эти вещи приходится делать блевотворными костылями, в разы менее эффективно.
"облегчает работу микроархитектурным разработчикам" - вы там долбанулись что ли? Процессор проектируется один раз и потом просто печатается сколько нужно, софта под него пишется неограниченное количество. Что это за прикол облегчать работу одному, чтобы потом сотни мучались?
Вообще, в классических, нормальных архитектурах цпу не принято терять данные. Сумматор помимо данных n-бит принимает и возвращает перенос, аналогично со сдвигами, умножение возвращает двойное слово и т.д. Всё это должно быть доступно разработчику на Ассемблере. Это вам не "безопасные" ЯВУ, молча отбрасывающие "лишние" данные.
И, кстати, найдите и покажите мне этот декодер на дайшоте, посмеёмся. Только не надо показывать в духе "вот исполнительные блоки, вот кэш, всё остальное стало быть декодер". Покажите конкретно декодер команд. Что-то сомневаюсь что он хотя бы 1% на ядро занимает на кристалле. Придумали какую-то отмазку чтобы выпускать всё более мерзкие наборы команд...
О какой потере данных идет речь ? В RISC-V имеются команды для работы с переносом, никаких проблем тут нет.
Никто, кроме создателей компиляторов (и ОС), не пишет на ассемблере. О чем вообще речь ? О том, что Вам как программисту не удобно писать на асме ? Ну извините, эффективная система команд не всегда может удовлетворять требованиям удобства отдельно взятыго индивида.
Настоятелно рекомендую Вам почитать статьи Паттерсона на заданную тему, перед тем как брызгать слюнями. Архитектуре RISC уже более 30 лет, возмущаться надо было в 80-х.
Ну как раз в сфере IoT и прочей мелочёвки типа контроллера стиральной машины на асме пишут. По той причине, что вендор предоставил компилятор языка, реализующего некое подмножество чего-то, похожего на Си, а всякие там llvm и gcc не завезли или они дико лажают.
Понимаете, ту же инструкцию умножения можно реализовать в железе нормально, а можно микрокодом на сдвигах и сумматоре. И тогда какое-нибудь умножение на 3 быстрее сделать вручную... вот только gcc о таких особенностях конкретного микроконтроллера нифига не знает и не будет.
Согласен, в embedded иногда пишут на асме и мне приходится с этим сталковаться. Но это большая редкость и такие случаи можно приравнять к компиляторам или разработке ОС. Для подавляющего большинства задач embedded разработчикам достататочно Си99 + библиотека HAL. В крайнем случае - интринсики для запрета/разрешения прерываний и доступа к CSR. Писать свою библиотеку математики это либо если уж совсем новая архитектура (GCC/LLVM еще не завезли), либо очень старая - компилятор уже не завезут.
В коменте выше человек брызжет словами пытась обвинить создателей архитектуры RISC-V в том, что якобы из-за отсутствия архитектурного регистра флагов там теряются какие-то данные. Большего бреда придумать сложно. Мне попадалась разная критика системы команд RISC, но такое вижу впервые. Отсутствие регистра флагов это типично для RISC.
В RISC-V имеются команды для работы с переносом, никаких проблем тут нет.
Отдельная инструкция для вычисления переноса вместо выставления флага при сложении/вычитании. Конечно, с помощью fusion в микроархитектуре можно сделать и то и другое в одном такте, но не факт, что это дешевле (с точки зрения числа транзисторов на кристалле), чем трекать отдельные биты флагов при переименовании.
А таскать с собой копию регистра флагов по всем стадиям конвейера и отслеживать зависимости это значит существенно меньше транзисторов ?
Macro-op fusion, если Вы про это, это микроархитектурное решение направленное на увеличение производительности. Оно может быть, а может и не быть реализовано. Пишут, что реализовать macro-op fusion весьма не просто. Но на микроархитектурном уровне вообще нет ничего простого. :) Изобрели эту фичу те же люди - Асанович и компания, при работе над RISC-V.
это значит существенно меньше транзисторов ?
Тоже не факт, надо сравнивать. Я к тому, что выкидывание флагов - это не просто бесплатное уменьшение количества транзисторов, надо чётко считать, даст ли это преимущество на конкретных задачах.
Оно может быть, а может и не быть реализовано.
Вот именно. Без него на коде с arbitrary length integers у RISC V может быть заметно больше микроинструкций, чем на архитектуре с флагами.
Кстати, Интел запатентовал (и использовал) саму идею fusion раньше , у Асановича с Вотерманом дополнение для конкретного случая.
Del
Выбранные примеры удручают своей неизвестностью. Можно было взять например:
- все новые ESP32 (ESP32-C*, ESP32-H*, ESP32-P*)
- RP2350 (Raspberry Pi Pico 2) - на выбор, два Arm Cortex-M33 или два Hazard3 RISC-V ядра
- AllWinner D1
Статья слишком рекламно-восторженная. Хотелось бы более взвешенного подхода.
"Нет хвоста легаси, как у х86" - чем это хорошо, не объясняется. Просто хорошо и всё тут, верьте мне. Зато умалчивается чем плохо - незрелый софт, начиная с компиляторов и всяких там jvm
"Нет жёсткой сертификации ядер, как у Аrm" - опять же, чем это хорошо, не объясняется. Просто хорошо и всё тут, верьте мне. Зато умалчивается чем плохо - под каждое семейство процессоров нужен по сути свой компилятор, который умеет оптимизировать вот конкретно этот набор инструкций. И, соответственно, каждый программу нужно перекомпилировать под каждый процессор, чего разумеется никто делать не будет. Т.е. в выигрыше у нас всякий IoT, где ради экономии пары микроватт потребления можно физически выпилить ненужные блоки. В минусе - масс маркет со всякими линукс дистрами и гуглоплеями. В штуках намного больше первых, а в деньгах - вторых.
Минус легаси, очевидно, в неодходимости разрабатывать и тестировать архитектуру чипа под всё накопившееся наследие. Да и тюнинговать систему команд становится архисложно из-за принятых когда-то неудачных решений по способам кодирования, например.
Хотя в плюсах, что очевидно, стабильная работа всего софта за последние 50 лет на новых чипах. Это дорогого стоит.
Так всё это нивелируется из за
под каждое семейство процессоров нужен по сути свой компилятор, который умеет оптимизировать вот конкретно этот набор инструкций. И, соответственно, каждый программу нужно перекомпилировать под каждый процессор, чего разумеется никто делать не будет.
Это то ли патетичное заламывание рук, то ли вообще некомпетентность: x86 обошлись без отдельного компилятора под каждую версию SSE в каждом поколении процессоров двух производителей (а ранее и пяти) — все, что нужно, включается флагами. А чтоб не думать — -march=native
А чтоб не думать —
-march=native
Для "коробочного" софта, который отдаётся кастомерам в бинарном виде, думать придётся.
Проблемы коробочниов… к утверждению про отдельный компилятор для каждого процессора они отношения вообще не имеют.
Я согласен, что отдельный компилятор не нужен, но разбираться с зоопарком расширений всё равно придётся.
Я согласен, что отдельный компилятор не нужен, но разбираться с зоопарком расширений всё равно придётся.
Теоретически, да. Но это будет влиять на производительность, и на практике видим совсем другое. Вот если берём базовую ISA RISC-V и вокруг выстраиваем обвязку из стандартных общепринятых расширений и прикручиваем компилятор gcc/clang то все вроде бы ок. А ещё в архитектуру можно встраивать свои расширения (открытые/закрытые), так же разработчики оптимизируют "свои" (берут за основу теже gcc/clang ) компиляторы под конкретные "свои" ядра и эти оптимизации почти всегда закрыты, но это не беда, просто берём все от одного производителя и радуемся, не жели страдаем с каким-то базовым компилятором для оной архитектуры. Проблема теоретически, может случится когда одно расширение есть в одних чипах, а в других отсутствует, тут уже одно и тоже приложение, которое опирается на эти расширения не будет работать, на других ядрах, хотя казалось бы одна экосистема к примеру risc-v 64 bit, linux, но это уже совсем другая история...
Закрытые расширения/оптимизации - отдельная история. Но открытые расширения вполне можно покрыть флагами gcc/clang, заинтересованные разработчики могут добавлять туда же оптимизации для своих процессоров.
когда одно расширение есть в одних чипах, а в других отсутствует
Вот про этот зоопарк я и писал. Разрулить можно (скажем, отдельными so под базовую архитектуру и разные расширения с загрузкой нужной в зависимости от фич железа), но требует усилий.
расширение есть в одних чипах, а в других отсутствует
Банальнейшая банальность в мире x86, которой десятки лет.
почти десяток версий SSE, полдюжины наборов 3Dnow! и AVX — это и давнее прошлое и повседневная реальность. А еще есть новые инструкции в стандартном наборе (POPCNT поднял много шума), разное поведение инструкций в зависимости от поколения (RDTSC, например) умершие расширения, поменявшие свое назначение префиксы…
Вот просто любопытства ради, а popcnt где-то кроме новостей шум поднял? Я просто так и не придумал кейс в котором кто-то обновляется на одиннадцатую винду на компьютере приближающемся к возрасту совершеннолетия, уцелевшем чудом, на условном Dual Core, обламывается и раздраженно начинает писать во все инстанции.
Ну или из последних новостей - обновляет драйвер NVidia до последней актуальной версии (для карты того же почтенного возраста, иначе бы не влезла в PCI-E 1.0) и тоже идет строчить гневные комментарии всюду куда дотянется.
Как-то сюрреалистично выглядит, нет?
Таскать библиотеки под разные версии. Давно ж решено
Ну да - чуть медленее будет компиляция
Да, как написал. Но у Интела развитие линейное - скажем, если на процессоре есть AVX2, то точно есть popcnt. А на RISC V расширения ортогональны - то есть можно сделать процессор с крипторасширениями без векторов, можно - с векторными без крипто, можно и то и то - и так со всеми. Так что для полной поддержки надо таскать 2^N библиотек, если для оптимизации кода применимы N расширений.
Там и простые инструкции на несколько расширений развалены, но насколько понимаю на всём сложнее микроконтроллеров можно расчитывать как минимум на GC.
x86 обошлись без отдельного компилятора под каждую версию SSE
Да-да, как раз во время первого SSE и конкурирующего 3DNow я выносил код обработки изображений в отдельную либу и компилил её под интел - icc, под amd - msvc. Второй, конечно, умел и под интел компилить, и машинный код был почти такой же, но код из-под icc работал на 20-30% быстрее, но только на интелах. Потому что они знали все подводные камни и затачивались конкретно под свои процессоры.
Возражая по форме вы фактически подтверждаете сказанное.
Если вы не напишете на ассемблере с использованием sse mmx функции декодирования DCT блоков, например, никакой компилятор вам их сам не напишет, какие бы флаги вы ему не включали, об этом мне рассказали те кто эти функции в интеле писал на ассемблере.
Потому, что это проприетарная Intel-овская ISA! В ней огромная часть закрыта всякими NDA и только Intel имеет право писать оптимизированные библиотеки и оптимизирующий компилятор для своих же процов. С открытыми архитектурами такого нет. Если система команд полностью опублиоквана со всеми нюансами, то рано или поздно под неё появится оптимизирующий компилятор который в подавляющем большинстве случаев будут генерировтать код оптимальней чем программист.
ну вот как раз подвезли наглядный пример вот здесь:
Я ускорил генерацию blurhash в 3̶6̶ 8̶7̶ 128 раз
найдите заголовок:
3. SIMD (SSE + NEON)
и вы увидите вот такую волшебную строчку в коде:
#ifdef __SSE__
и вот такие типы:
__m128
согласитесь это совсем не похоже на флаг компиляции, может быть когда нибудь компиляторы научатся переписывать код в других типах, но пока прогресс туда явно не дошел. Но чтобы работал код именно под этим иф-дефом какой-то флаг компиляции все таки нужен, но без кода написанного руками не обойтись и я думаю ближайшие лет 10 это не изменится, я что-то не слышал чтобы кто-то учил ИИ применять SSE по его ИИ разумению.
Я прочитал Вашу статью пользователя @homm спасибо.
Замечу, что бОльшая часть выполненных оптимизаций носит алгоритмический характер, т.е. прграммист постепенно улучшал сам алгоритм обработки данных - вводил кэширование часто используемых данных, предварительный расчет массива констант и т.д. Компилятор на такие изменения кода пойти не может по праву, так как это вотчина именно программиста.
На счет того, что компилятор без пинка сам не справляется и не переделывает код на SIMD. Ну так функция memcpy() написанная в лоб тоже не будет оптимизирована до использования SIMD. :)
И третье. А Вы пробовали собрать Сишный код с использованием icc на x86 ? Вангую прирост производительности еще минимум в два раза. Может быть даже и массажирование не потребуется.
А Вы пробовали собрать Сишный код с использованием icc на x86 ?
так я как раз в интеле и работал 20+ лет назад. проект назывался интел-перфоманс-примитивы IPP. Насколько я помню мелко-мягкий компилятор казался мне все таки понадежнее (производительность станет совсем не важна если у вас ваша программа падает, или не коректно С-шные конструкции воспринимает), в любом случае мы его как основной-референсный использовали, но за 20 прошедших лет мне никогда не попадался под руку интеловский компилятор, ничего про него теперь не знаю. х86 платформу использую как вспомогательную, на ней перформанс никого особо не интересует, если он вообще кого-то теперь интересует. Я имею ввиду перформанс на локальном ПК, а не какой-то облачный-распределенный-параллельный-абстрактный перформанс о котором теперь принято рассуждать безотносительно железа которое его должно обеспечить.
Сотрудники Интел использовали майкрософтовский компилятор вместо доморощенного ? Это что-то очень странное.
в то время, по крайней мере, мы в этом ничего странного не видели, во первых потому что интел все таки железячная кампания в основе своей, а не софтовая. Софтовой инфраструктуры (IDE не говоря уже об операционной системе) своей у Интела и сейчас нет насколько я знаю. Когда вы разрабатываете свой компилятор вам в любом случае нужен (как минимум не помешает) какой-то другой компилятор для сравнения как минимум, а если у вас нет своей IDE, то использование компилятора из IDE которую вы используете выглядит как естественное решение, по моему.
На сколько я понимаю-знаю разработка интеловского компилятора велась по договоренности корпораций и интегрировалась с Вижал Студией в первую очередь как альтернатива встроенному компилятору.
привет ex-IPP-шнику от ex-IPP-шинка. Стоит все же отметить что уровень амбиций Интел в области своего компилятора менялся со временем, сил в него было вложено компанией не мало, и был даже период когда мы работая над IPP (и не только мы) работали с командой компилятора, с тем чтобы научить авто-векторизатор распознавать типовые конструкции циклов и некоторые вещи команда компилятора приняла от нас, но справедливости ради, кажется чаще команда компилятора учила нас "правильно" писать код на С, т.е. оформлять код так чтобы убирать неоднозначности для компилятора, и он бы легче выявлял векторизуемые блоки. Было время когда существовало мягкое требование чтобы программные продукты Интел компилировались Интеловским компилятором (IPP ведь выпускалась собранная именно Интеловским компилятором). Большое достижение у компилятора было когда они смогли без ошибок компилировать ядро линукса, но долгое время были недочеты на С++ коде. Сейчас вроде бы Интеловский компилятор довольно неплох и в С++, правда Интелу теперь наверное не до компилятора, но это уже другая история
Сейчас то у них llvm-based icx, так что фронт от clang с тем же уровнем поддержки С++. Вопрос только, перетащили ли туда всю логику оптимизации из icc - а то какое то время icc уже не поддерживался, а icx ещё нормально не оптимизировал.
кажется чаще команда компилятора учила нас "правильно" писать код на С, т.е. оформлять код так чтобы убирать неоднозначности для компилятора, и он бы легче выявлял векторизуемые блоки.
Да, это отдельное искусство. Но по крайней мере компиляторщики стремились к тому, чтобы для каждой новой ассемблерной инструкции был паттерн в исходнике, который её использовал.
работали с командой компилятора, с тем чтобы научить авто-векторизатор распознавать типовые конструкции циклов и некоторые вещи команда компилятора приняла от нас
но этого я уже не застал к сожалению, с компиляторщиками мы еще не общались особо. Это было уже после меня. Жаль что мне тогда пришлось уйти, хорошее было время.
и только Intel имеет право писать оптимизированные библиотеки и оптимизирующий компилятор для своих же процов.
Вот с этим как раз проблем нет, контрибутить оптимизации в gcc/clang или писать что-нибудь типа этого никто не запрещает.
Разумеется, контрбьютить в код компилятора никто не запрещает. Проблема в раскрытии инфорамации об особенностях новых инструкций. Сотрудники компании Intel обладают гораздо более широким представлением о том, как написать оптимальный код для своего процессора. По этому они создают всякого рода IPL/IPP и распространяют их только в виде бинарного кода.
Сотрудники компании Intel обладают гораздо более широким представлением о том, как написать оптимальный код для своего процессора.
Как минимум они могут заниматься этим полный рабочий день за зарплату ) Но при этом по уже вышедшим процессорам разные умельцы добывают микробенчмарками более чем достаточно информации.
на самом деле знания особенностей новых инструкций просто доступны сотрудникам раньше чем другим на рынке, и поэтому есть возможность поддержать выпуск нового процессора (и его продажи есс-но) сопроводив запуск процессора выпуском оптимизированных для него библиотек. остальным игрокам на рынке знание новых инструкций становится доступно с выходом процессора в продажу, т.к. техническая документация по нему становится доступной так же, а тонкости поведения рано или поздно выявляются экспериментами
никакой компилятор вам их сам не напишет
Сам компилятор - нет, а вот его разработчики вполне. Собственно, я сейчас говорю конкретно про интеловскую IPL (image processing library), где как раз все эти DCT вылизаны до блеска. Но только на процах intel
По части сертификации в риск5 есть процесс из двух шагов — "пакетные/наборные спецификации" типа RVA24 и наборы инструментов, в том числе открытых, для проверки соответствия нового чипа этим спецификациям.
В части усиления кроссовместимости чипов разных разработчиков по системе команд, кажется очевидным, что появится однажды какой-то совместный процесс у Байкала и Ядра в рамках ассоциации риск5.
"Нет жёсткой сертификации ядер, как у Аrm" - опять же, чем это хорошо, не объясняется.
Для людей, решающих, на чём строить датацентры и облака - это скорее минус.
Как понимаю, речь не про отсутсвие сертификации, а про "невозможность" создания другого органа сертификации. То есть монопольная зависимость архитектуры от одного поставщика.
Всё верно, мысль в этом была
Но при этом есть некая уверенность, что софт, скопилированный под, скажем, ARM 8.2 будет работать на любых процессорах с соответствующей лицензией и сертификацией - хоть на новых моделях от текущего поставщика, хоть на процессорах другой фирмы. А вот насколько это работает с RISC V - пока непонятно.
Ищите в описании проца такую запись "Полное соответствие профилю RISC-V RVA22" — это пример из чипа Sophgo SG2380.
Полное соответствие профилю RISC-V RVA22
И кто это проверял? "Мамой клянусь"?
Как и в любом федеративном продукте типа ядра Линукса или шины PCIe))
Вообще-то тесты свободно доступны, любой пользователь их может прогнать и опубликовать результаты, и вендору будет крайне тяжело их оспорить. Что-то подобное есть у Web-браузеров - тест на соответствие стандартам JavaScript и HTML.
С проприетарными процами всё строго наоборот - как хозяин-барин решит, так и будет, а пользователи должны продолжать давиться этим кактусом. Как там у Интела с дохнущими камнями, кстати ? Признали уже проблему или всё еще отмазываются фразой "неправильная эксплуатация привела к деградации..." ?
Можно добавить, что в России уже есть свое решение на RISC-V
Как-то очень много воды и картинок. Мне кажется что преимущества и польза для общества у RISC-V те же, что и у любого открытого проекта
Невозможность монополизации и независимость от внезапного приступа придури/жадности единственного владельца
Гораздо более жесткая кокнуренцияи между гораздо большим и разнообразным числом действующих лиц
Собственно все то же что выделяет более открытую ARM на фоне более закрытой x86.
Каких-то волшебных преимуществ RISC-V само по себе не несет и будет повторять историю ARM медленно развиваясь от простых и слабых процессоров/микроконтроллеров к более сложным и мощным.
По сути это повторение истории ARM с более явно выраженными преимуществами открытости.
Единственное реально хорошее место в статье - подчеркивание роли микроархитектуры для производительности. Сама по себе система команд не делает RISC-V лучше, преимущества открытости организационные и политические.
Грубо говоря когда Джобс захотел выйти в новый сегмент мобильных устройств на х86 была монополия Intel и дурь интел как единственного принимающего решения лица сгубила перспективы архитектуры. Иначе все мобильники сейчас могли бы быть на x86. А большая открытость и конкуренция на ARM позволила найти компании, которые дурью не страдали и увидели перспективы.
Примерно так пять столетий назад в Китае единое и мопнопольное правительство приняло решение отказаться от технического прогресса и захвата заморских колоний, а в Европе среди множества независимых друг от друга и конкурирующих между собой правительств нашлись те, кто решил в это вложиться. Колумб несколько королей обошел в поисках финансирования, пока не нашел достаточно смелых.
Ну и замедление роста ARM вполне естественно - пропадает эффект низкой базы.
И да Windows Phone была очень плохой и идеей и технологией. Детище маркетологов и красивых отчетов для начальства и журналистов, совершенно не рассчитанное на использование в реальной жизни.
И да Windows Phone была очень плохой и идеей и технологией.
Вот сейчас обидно. Как имевший в руках тогда те телефоны - я все еще скучаю по их простоте, по тому какой у них был интерфейс, по самой концепции живых плиток, по тому как там была реализована система к доступу к фото/видео, по интеграции с сервисами того-же майкрософт.
Еслиб гугл не душил из-за конкуренции с ведром и майки чуток более открыли доступ до железа - мыб видели третьего адекватного игрока на рынке, который имел фанбазу.
Поддерживаю, Windows Phone была новаторской и смелой с точки зрения UI/UX; NOKIA пичкала WP-смартфоны крутыми аппаратными решениям, вроде OLED-дисплеев и беспроводной зарядки. Сейчас это стало стандартом в отрасли, а тогда было у единиц. Умерла она из-за отсутствия софта (того же Google) и поддержки от сторонних разрабов, а не от чего-либо другого.
Я ни секунды не спорю с тем что есть люди, которым они могли нравится, но тут уже в дело вступает статистика - те люди, которым они радикально не понравились, как и мне например, составляют подавляющее большинство.
Я еще превосхожно помню статьи тех времен с одним общим рефреном "ну почему люди такие тупые и не понимают, что на самом деле это удобно, надо больше вкладываться в маркетинг чтобы обьяснить людям, что это на самом деле удобно".
Те вещи, которые действительно удобны, не встречают такого молчаливого сопротивления и их не надо проталкивать силой, они наоборот сами распространяются с вирусным эффектом.
С технологической же точки зрения они сделали феерическую глупость полностью сломав обратную совместимость приложений - первый раз с выпуском Windows Phone, второй раз с выпуском 8 версии. Два раза надо было полностью переписывать приложения. Такая технологическая политика могла бы и Android погубить.
Если бы майки вместо Phone развивали Windows Mobile они вполне могли бы занять место Android сделав это вовремя или остаться третьим игроком сделав это чуть позже. Имели бы примерно те же достоинства и недостатки что и Android.
Windows Phone была очень плохой и идеей и технологией. Детище маркетологов и красивых отчетов для начальства и журналистов, совершенно не рассчитанное на использование в реальной жизни.
Вообще ни разу нет, как раз все, кто пользовался в реальной жизни, были довольны, ведь в то время это было лучше из двух миров: удобный не лагучий интерфейс даже на слабом железе и относительная открытость, нормальный файловый менеджер и т.д. Там были другие проблемы, в т.ч. с СДК и в целом со взаимодействием с разработчиками приложений, поэтому платформа начала загибаться банально из-за отсутствия многих важных (для людей) программ. А запуск андройдовского ПО то ли не допилили, то ли специально (ошибочно) зарезали...
Вот уж не совсем, я согласен. Был владельцем данного аппарата, мне он очень нравился (Windows Phone 8, Windows Phone 8.1, моя модель не поддерживала переход уже на новую версию) и я скучаю конечно по нему, но вот гвозди в крышку гроба забивала придурь создателей в плане апи, форматов фалов, etc. это не давало возможностей как обратной совместимости, так и владельцам некоторых не слабых устройств обновляться.
Собственно все то же что выделяет более открытую ARM на фоне более закрытой x86.
Довольно произвольное утверждение. x86 точно так же можно лицензировать и допиливать. AMD именно этим и занимается. А раньше ещё были VIA и ещё кто-то. Я думаю, что причины успехов ARM последнего времени в том, что сама архитектура гибче
x86 точно так же можно лицензировать и допиливать.
Ну попробуйте ) Сейчас его могут использовать только те, кто получил лицензию в те времена, когда Интел её давал (и их правопреемники).
Систему команд даже лицензировать не надо. Патенты на неё истекли. Но собрать из готовых блоков рабочий процессор, как у АРМ не получится, конечно.
Она разве не авторским правом защищается? Там сроки побольше. Ну и конкретно x86-64 появился позже и насчёт него надо отдельно с AMD договариваться.
Думаю, что нет. Во всяком случае интел судилась с цайрикс из-за патентов, а не из-за авторских прав.
Вообще-то нет. У AMD и еще буквально пары крохотных компаний которые до сих пор делают такие процессоры есть лицензионные соглашения заключенные много десятилетий назад. Новые лицензии уже много десятилетий получить невозможно.
я не вполне точно там выразился. У АРМа разработчики получают конструктор из которого они собирают процессор, который потом производят, как хотят. Интел таким, конечно, не занимается. Но, с другой стороны, патенты на системы команд истекли. То есть, лицензировать их не надо. То есть, кто угодно может сесть и сделать x86-совместимый компьютер. Всё что нужно это немного денег и времени
Ну и кстати, даже если бы патенты не истекли, Интелу всё равно не удалось бы их зажать. Его бы заставили их лицензировать по разумной цене по антимонопольному законодательству. Точно так же как qualcomm заставляют лицензировать патенты на wi-fi и 5g
У АРМа разработчики получают конструктор
Или только спецификацию на ISA и рисуют своё ядро с той же системой команд (архитектурная лицензия).
Так x86 же тоже развивается 5 версий SSE две версии AVX, x86-64. Насколько я помню срок действия патентов 25 лет, из под них еще даже x86-64 не должна выйти. AMD в свое время заключила кросслицензионные соглашения с Intel но это их внутренне дело.
Аналог Pentium 3 наверное можно сделать без лицензий но на нем никакой современный софт не пойдет.
И если бы лицензия на x86 продавалась на нее бы длинная очередь выстроилась - как минимум из досанкционных китайцев, да даже и русских вроде Байкала которые лицензию на АРМ покупали.
Apple бы сделала свои ядра на x86 и производила бы их на современных техпроцессах.
Но когда Intel им отказала непосредственно в процессорах, купить лицензию на x86 было негде.
Вместо этого все долго и мучительно изобретали высокопроизводительные ARM почти два десятилетия.
И если бы лицензия на x86 продавалась на нее бы длинная очередь выстроилась - как минимум из досанкционных китайцев
Китайцы, кстати, вполне успешно разрабатывают х86 процессоры в сотрудничестве с VIA для собственного рынка.
Это как раз "старые лицензиаты", цепочка тянется к Cyrix.
Не совсем, к Centaur Technology, Cyrix уходит к AMD.
Обратите внимание на форму сотрудничества - это не покупка лицензии, а совместное предприятие с фирмой, которое владеет лицензией несколько десятков лет. VIA кстати тоже лицензию не покупала, она купила фирму с такой лицензией основанную аж в 1995 году - Centaur Technology. Есть еще одно такое совместное предприятие с AMD и причина у него точно такая же - невозможность просто купить лицензию.
С ARM никто такие сложные схемы не изобретает, просто покупается лицензия - либо на ядро либо на архитектуру.
Не совсем так. RISC-V это не просто еще одна система команд с открытой лицензией (таких, кстати, есть несколько: OpenRISC, OpenPOWER и т.д.), RISC-V это хорошо выверенная, подкрепленная десятилетиями научных исследований, система команд нацеленная на производительность и эффективность исполнения. Целями создания RISC-V было не удобство программирования или написания очередного компилятора, а простота реализации на микроархитектурном уровне, минимум зависимостей между командами, простая схема декодера, легкость конвейеризации, относительно высокая плотность кода, энергоэффективность и т.д. Получилось ли у Паттерсона и Асанович достичь этих целе - мне судить сложно, есть много "за", как и много обьективной критики.
Как идея оно мне нравится (даже симулятор базового набора команд писал из интереса, чтобы заодно одну рабочую идею обкатать). Но пока не вижу конкретных реализаций, пригодных для энтерпрайза и HPC.
Про конкретные реализации я четко написла в самом первом комменте. Их нет и не будет еще достаточно долго - кто-то должен будет пройти длинный путь создания высокопроизводительной микроархитектуры, при этом все остальные монополисты в виде Intel, AMD, IBM и ARM будут тщательно совать палки в колёса.
"Два из наиболее известных продуктов Беркли - LSD и Unix. Я не думаю, что это совпадение"
Как же вы задрали со своими супергероями
А можно и мне имхо выкатить? Я 15 лет занимаюсь системой разработкой. Прошёл mips, e2k, powerpc, x86, arm на максимальной сложности со всеми дополнениями.
Не будет r5 массовым. Не нужен. Деньги нужны - а r5 не нужен. Займёт какую-то определённую долю, порядка 0,1% и тихонечко там будет подгнивать.
Почему то о нем модно говорить и рассказывать как он захватит мир - прям rust в мире кремния. А по факту очередная бестолковая поделка.
Вся мякотка современных камней вотвсяких акселераторах, npu, gpu и прочих свистелках, которые закрыты, и поставляются с бинарным микрокодом. А какой смысл в r5 тогда?
вотвсяких акселераторах, npu, gpu и прочих свистелках
Оно так и есть — все большие чипы на риск5 именно тут, в ускорителях. Так у Алибабы, Тенсторрента, Эсперанто, Вентаны, Семидинамикс...
Плюс со стороны универсальных микроконтроллерных задач уже полно процессоров на риск5. Тут прям всем миром переход виден — от тотального у WCH и Еспрессив до попробовать — Ренессаc, NXP, Нордики и даже итальянцы из СТМ пошли сюда только что. Про спецконтроллеры мало говорят, но их делают почти все, даже наши Кравтвей и Аквариус и всякие разработчики базовых станций, например))
На следующий год, очевидно, что будет много выходить процессоров с риск5 в сегменте ПК/ноутов. Первые 4-8-16 ядерные уже вывши в этом году в готовых устройствах, но это "на любителя" — дозревают драйвера, компиляторы и ОС. А на следующий год выходят и наши, например Ядро уже получило первую выпечку собственного риск5 чипа для замены АРМов в своих планшетах.
Пользователь @xabar прав, высокая производительность создается не системой команд, а микроархитектурными решениями, а они все напрочь запатентованы и никто из мэтров ими делиться не собирается. Так, что путь RISC-V к олимпу HPC будет очень и очень тернист. Но я, на против, уверен что это произойдет и настанет момент когда камни на архитектуре RISC-V от разных вендоров, один за другим, начнут бить рекорды производительности. Я даже почти уверен, что Intel, почувствовав запах своей подгорающей задницы, возглавит эту гонку.
Совершенно согласен. и примеров такой гонки и не всегда успешных экспериментов в риск5 на грани передовой производительности уже есть. То есть по микроархитектуре новоприбывшие разработчики ядер быстро набираются опыта по мере выпуска собственного кремния.
А многие из дизайн-центров — это бывшие сверхопытные в микроархитектурах архитекторы из Интела, АМД, Квалкома, Элла, Нвидии и т. д. Пример Тенсторрента под прямым руководством Джима Келлера очень характерный.
высокая производительность создается не системой команд, а микроархитектурными решениями, а они все напрочь запатентованы и никто из мэтров ими делиться не собирается
неужели кто-то думает что за 30-50-70 лет (как считать) разработки и развития систем команд, а микроархитектурных решений остались какие-то пропущенные варианты которые являются такой серебрянной пулей, то есть решением которое способно произвести переворот в микросхемо-строении, или просто что-то кардинально улучшить?
Может давно пора уже посто учиться качественно воспроизводить то что есть, как-то систематизировать, выработать критерии эффективного применения? Ведь чтобы сделать что-то свое да еще и лучше надо наверно изучить и знать и на практике подтвердить это знание по уже существующей базе решений, или это не обязательно?
Очень сильно утоптано поле фон Неймановской архитектуры, на нём действительно больше ловить нечего. Но есть и другие, менее традиционные подходы к организации вычислений, в том числе нейровычислители с массовым параллелизмом различной топологии, и там одно время было посвободнее. Подавляющее большинство мелких микропроцессорных компаний и стартапов как раз пытаются взрастить урожай на этой почве.
Прошёл mips, e2k, powerpc, x86, arm
Жаль, конечно, что не дошли до сегодня системы команд чипов из времён позднего союза типа Кронос или развитие линеек на основе PDP11. Дотащили только эльбрусовский е2к.
Но массовым тиражом (1,8 млн. шт. в этом году) вышел риск5 чип АМУР на зеленоградской фабрике Микрон. Он полностью спроектирован в России, включая использование вычислительного опенсорсного ядра из Петербурга. Причём разработчики АМУРа фактически использовали исходники ядра без разработчиков этого ядра. И это первый такой удачный опыт.
Да, я тоже хотел бы видеть продолжение советской линейки PDP11 вместо E2K. Взяли бы комплект КН1811 или КН1831ВМ1 и переложили бы его на современные наномеры, предварительно расширив слово до 64 бит.
MIK32 АМУР, несмотря на некоторые нюансы, оказался не плох. АЦП бы ему подправить (Vref увеличить, битности добавить), увеличить EEPROM до 16К и вполне годный будет микроконтроллер, не хуже всяких STM32. :)
АМУР-2, вроде как, предъявили на Микроэлектроника-2024 в скорых планах и он в разы шибче первого АМУРа.
Тем более опыты МИЭТ и Ядра по выпуску экспериментального риск5 чипа Хаки на Микроне позволяют говорить о технологической возможности резкого роста в характеристиках. Как минимум, частоту можно поднимать в 2-3 раза.
А где об этом всём можно почитать ?
Про Хаки тут.
Про АМУР-2 не публично пока.
Про Xackee было в новостях, больший интерес в этом деле представляет MPW-сервис от Микрона как средство взращивания кадров. А вот про АМУР-2 слышу от Вас впервые.
Про К1948ВГ1Т, он же MIK32-2, тут в планах Микрона
Аналогом стоит STM32H743 изготавливаемая по технологии 40нм. ИМХО, Микрону такое на своём производстве не потянуть просто в силу отсутствия технической возможности изготавливать flash, а её у STM-ки несколько мег. И с тактовой частотой тоже не выйдет. Ошиблись наверное в буковках. :)
Да, сам удивился такой прыти Микрона.
С другой стороны, у них в производстве с 2014 года есть опыт Эльбрус-2CМ, который на 90 нм имеет 300 МГц.
А по поводу флеша, есть большая мировая практика ставить его отдельным кристаллом поверх основного в одном корпусе. Или не ставить вообще, как в двухядерном британском RP2350 с риск5, например.
Проблема не в том, чтобы поставить, а в том чтобы произвести. На сколько мне известно, нет в России производства flash памяти. Можно купить у китайцев готовые кристаллы, но это будет уже совсем не тот АМУР. :-)
Если исходить из текущих реалий, то в АМУРе есть накристальные 8 кБ флеша и доступна внешняя адресация до 2 ГБ. Сейчас в продаже есть модули с 32 МБ внешнего флеша. То есть для чипа первого уровня это нормально.
С другой стороны, в воронежском риск5 чипе К1921ВГ015 стоит 1 МБ накристального флеша. Он второго уровня, и тем самым существенно дешевле.
Есть планы у Байкала на риск5 чип с внешним флешем. Они могут его сделать на Микроне или на заграничной фабрике. И это двойной плюс — по цене и по доступности производства.
В АМУРе нет flash-а, там EEPROМ. Так мало её потому, что она занимает большую площадь в виду древности технологии производства. Про воронежский камень ничего не знаю, но скорее всего там flash будет на внешнем кристалле, так как такой объем микроновской EEPROM просто не утолкать на кристалл.
В целом, МК с внешней микросхемой flash тоже годен, но для загрузчика всё же надо чутка побольше обьем EEPROM, хотя бы 16К. :-)
PS: Мне удалось упихнуть свою задачу в 8К EEPROM на АМУРе, но пришлось попотеть и полностью отказаться от HAL библиотек.
Кстатии, не знаете, вот это что за железки?
Займёт какую-то определённую долю, порядка 0,1%
Как ни парадоксально, но это уже произошло. Причём даже выше 1% участия риск5 в "больших" чипах :)
Байкал реализовала в своём серверном 48-ядерном АРМ процессоре Байкал-С ядро риск5 для доверенной загрузки и управления чипом.
МЦСТ в линейке Спарк-процессоров выпустила новый чип с дополнительным риск5 ядром управления питанием.
Сюда же симпатичный пример на перспективу, правда про "мелкие" чипы — компания Бештау в Ростове проектирует риск5 процессоры микроконтроллерного применения для замены чипов с системами команд 8051 и АРМ в своих периферийных устройствах — клавиатуры, мыши, мониторы и т.п.
Если так считать, то Minix - очень популярная ОС )
МЦСТ в линейке Спарк-процессоров выпустила новый чип с дополнительным риск5 ядром управления питанием.
А помоему в эльбрус добавили, и не только для управления питанием/частотой, а для управления датчиками и вентиляторами. Раньше, как я понял, информация с датчиков обрабатывалась прямо в основном конвеере, а динамических частот небыло вообще. Теперь это делает независимый процессор, а из ядра и шк все это вилкой вычистили и поэтому видимо на e2kv7 обратная совместимость и поломана (как заявлялось трушкиным)
Ви таки не правы. Все решат бабки. Будут вливать в RISC-V - будет в каждом утюге, не будут - не будет. Тот же МИПС и АРМ суть те же РИСК, не мне вам объяснять. Тренды рулет крч. Также как андроид вывезли, так и RISCV могут.
Так чьи акции-то покупать? Если обещают рост рынка 40%+ в год - надо бы откусить кусочек...
WDC? BABA? Intel? Google? или кто ?
То чувство, когда начал заниматься RISCV и встречался с Кристе, до того, как это стиало мейнстримом)
RISC-V — звезда родилась: x86 не у дел, ARM сломала обе ноги