Ну деклараций о намерениях в этом мире всегда хватало… Я то имел в виду, что более или менее реальная жизнь началась, когда ARM взялся за SVE. Имея на вооружении только 128 bit SIMD (NEON) на этом рынка кокнурировать сложно…
Вот что подумал — arm — консорциум вендоров. А Интел — одна компания. И решения в ней принимает гораздо меньшее число людей. А людям свойственно ошибаться. И поэтому в x86 гораздо больше странных решений…
Согласен. Всегда говорил, что не надо программистам мозги ассемблером забивать. У них и так есть баги, дедлайны и начальство. :) И компилятора тоже не надо, самый лучший язык — Java :)
Вот в том то и дело. Хороший дизайн ISA должен закладывать возможности расширения с самого начала. только вот осознали этот очевидный в общем то факт уже в конце 80'х…
Да так оно примерно и происходит. Вот статья, откуда я позаимствовал графики. blog.acolyer.org/2017/06/19/hardware-is-the-new-software
Если бы не этот ROM front end x86 давно превысил бы все разумные пределы. Там же оседают другие элементы ISA -например счетчики. Только этот ROM тоже не маленький и не бесплатный. Но поскольку все это не от хорошей жизни никто никогда не расскажет во что он обходится…
Насколько я помню спецификации SVE датируется 2017-2018 годом. Ну то есть можно сказать что именно в этот момент arm стал серьёзно заглядывать на ентерпрайс рынок
Нет, тоже не сколько хочешь. Если бы это так было — не было бы троттлинга. А они троттлятся тока в путь. Power envelopes никто не отменял для серверов. Но там они связаны скорее с отводом тепла.
О, кстати. Надо будет как нибудь в следующий раз написать про частоту, длину пайплайна и энергопотребление. Это моя любимая тема. Я ещё помню p4, который работал на 10ГГц и охлаждался жидким азотом :)
Не уверен. Мне в детстве пришлось повозиться с декодированием битстримов по хаффмановским табличкам. Это сугубо последовательная операция. А при добавлении каких то маркеров появляется избыточность.
По большому счету это так. Обычно проблемы front end связаны или с предсказанием ветвленией или с промахами в instruction cache. Проблемы с декодером — экзотика. Хотя если еще увеличивать длину командного слова — она может стать реальностью.
:) Я тоже слышал эту байку. Не уверен, что правда, оч давно было. Но хорошо коррелирует с мыслью о том, что в истории X86 гораздо большую роль играло стечение обстоятельств, чем изначально заложенная логика :)
Только вот чем проще ISA — тем больше инструкций содержит код. Длинные инструкции CISC в RISC превратятся не в короткие инструкции, а в огромное количество коротких инструкций. И мне почему-то кажется, что код на хорошо спроектированной CISC ISA окажется короче, чем на RISC..
Это отчасти справедливое замечание. Но тут я бы хотел послушать компайлерных людей, ибо самому тяжело сравнивать. Чисто теоретически CISC может иметь преимущество, когда ставит в соответствие более частым инструкциям или последовательностям более короткие коды (Huffman, arithmetic). Но проблема будет в том, что это будут команды переменной длины и декодировать их можно будет только последовательно.
Горестная судьба Itaniuma вся прошла перед моими глазами. Поделка, впрочем не была так плоха чтоб с первого дня окрестить ее Itanicом. Однако, это EPIC…
Согласен. Всегда говорил, что не надо программистам мозги ассемблером забивать. У них и так есть баги, дедлайны и начальство. :) И компилятора тоже не надо, самый лучший язык — Java :)
Если бы не этот ROM front end x86 давно превысил бы все разумные пределы. Там же оседают другие элементы ISA -например счетчики. Только этот ROM тоже не маленький и не бесплатный. Но поскольку все это не от хорошей жизни никто никогда не расскажет во что он обходится…
Насколько я помню спецификации SVE датируется 2017-2018 годом. Ну то есть можно сказать что именно в этот момент arm стал серьёзно заглядывать на ентерпрайс рынок
Нет, тоже не сколько хочешь. Если бы это так было — не было бы троттлинга. А они троттлятся тока в путь. Power envelopes никто не отменял для серверов. Но там они связаны скорее с отводом тепла.
О, кстати. Надо будет как нибудь в следующий раз написать про частоту, длину пайплайна и энергопотребление. Это моя любимая тема. Я ещё помню p4, который работал на 10ГГц и охлаждался жидким азотом :)
B Opcode Mode R Src Mode R Dst
нашел в википедии. Ну да — логика за этим есть. Но как расширять набор команд?
Это отчасти справедливое замечание. Но тут я бы хотел послушать компайлерных людей, ибо самому тяжело сравнивать. Чисто теоретически CISC может иметь преимущество, когда ставит в соответствие более частым инструкциям или последовательностям более короткие коды (Huffman, arithmetic). Но проблема будет в том, что это будут команды переменной длины и декодировать их можно будет только последовательно.