Ранние ЭВМ это "последовательное исполнение команд" (in order execution) Позднее придумали раздробить исполнение команд на стадии (pipeline) что бы позволить независимым инструкциям запускаться не дожидаясь завершения предыдущей. Примерно в это же время примерно для таких же целей придумали superscalar - исполнение независимых инструкций параллельно на разных юнитах. Еще позже добавили к этому Out-of-order - то есть выявление независимых инструкций в буфере команд и исполнение их вне очереди. Все подходы дополняют друг друга и оказывают синергитический эффект и в современных высокопроизводительных процессорах являются обязательными к реализации, хотя и без проблем то же не обошлось. Как бы там нибыло это все было во времена когда быстрые программы писали только на ассемблере и ассемблер был сделан так, что бы быть удобным для программирования (CISC). Когда языки высокого уровня (например Си) начали вытеснять ассемблер, народ задумался о том что бы сделать машинный язык проще для исполнения (RISC) максимально приблизив его к микрооперациям. Третьи вообще предложили что раз пошла такая пляска в сторону упрощения тогда надо и другие костыли выкидывать и генерировать сразу параллельный код для исполнения. (VLIW) Последняя идея вспоткнулась об то, что для того что бы генерировать качественный параллельный код надо знать что у пользователя за железо и как именно он собирается эксплуатировать софт. В специализированных вычислителях где заранее известно какая программа и с какими данными будет работать - это отлично себя зарекомендовало. В десктопном же софте где программист пишет софт на все случаи жизни, маинтейнер собирает это все под условное железо, а пользователь использует 1% функционала от этого всего, реалии понятное дело другие, статически тут не подстроишься. Но все постепенно меняется, 3d графика уже давно пришла к незаметной компиляции шейдеров перед запуском для более эффективного использования железа, раст постепенно к этому же подбирается, ускорять программы засчет железа уже некуда
Спасибо, лаконичный и вполне понятный roadmap любого курса по АЭ. Я бы ещё добавил туда в качестве постоянной напоминалки феномен legacy: ситуацию, когда некоторая техническая задача решена столько-то десятилетий назад, но в силу разных причин решать её по-новому пока не хотят, а вместо этого изобретают костыли.
Когда говорят Фонейманская архитектура тогда подразумевают что есть ещё другая архитектура - Гарвордская. Отличие архитектур состоит в том что Фонейманской архитектуре есть общее пространство памяти для данных и команд (то есть команды могут выступать как данные и наоборот данные как команды например Intel8086) , а в Гарвардской архетиктуре область программ и данных разделены( например PIC12F1840). То есть при каком либо сбое в Гарвардской архетектуре невозможен программный переход на область данных поэтому предполагается как боллее надежная.
"Упаковкой" команд в vliw архитектуре занимается компилятор, ровно так же как это происходит в risc процессорах. Почему-то повышенная трудоёмкость написания программ и сложность компиляторов для risc процессоров вами аккуратно обойдена стороной. Совпадение? Не думаю! ;-) Да и про остальные недостатки risc архитектур вы почему-то умолчали, зато изъяны х86 вы расписали во всех деталях. Попахивает каким-то заказом.
Не вполне ясно, о какой «повышенной трудоёмкости» и «сложности компиляторов» вы говорите. В случай vliw всё понятно: одна инструкция довольно длинная, нужно представлять граф выполнения в виде зависимостей микроинструкций по данным и управлению, некоторой сложной логикой их переупорядочивать, а затем упаковывать в эти самые длинные инструкции. Любая недоупаковка - проседание производительности (и пузыри в конвейере). А в чем состоит аналогичная сложность для RISC, в которой инструкции, наоборот, заведомо простые и быстрые? Про «заказ» не понял… Вы намекаете на то, что курс называется «Архитектура RISC-V»? Ну так можете не намекать, он действительно так называется ☺
Как мне дороги Линуксоиды. Хотелось бы удавить их еще в колыбели. Они даже не представляют что я (100% виндовс пользователь ) сейчас думаю. А лектор просто написал две строчки кода и программа заработала. И не моргнув глазом пошел дальше!
Тут большое упущение и историческая несправедливость. Первая 64-битная архитектура MIPS (R4000, ISA v3) появилась ещё в 1992-м году. Широко применялась в игровых консолях Nintendo-64, и Sony Playstation, и не только. Куда там амд64...
Вся фишка в RARS-е. Если вы сделаете аналогичный ролик по «Эльбрусу или тому же Байкалу», очень многие, несомненно, будут вам благодарны. Но, боюсь, без эмулятора достаточной степени наглядности это будет довольно затруднительно.
@@unx7784 ролик то хорош, но я про риск архитектуру, про то что процессора то нет, а Эльбрус то есть, готовый , развивай и распростроняй, зачем делать кучу разных кристаллов разной архитектуры и инструкциями, это как погонишся сразу за всеми зайцами, и не одного не поймаешь.
@@user-ks5rj3cl2u процессоров RISC-V десятка два одних только производителей. Например, Western Digital или HiFive - поинтересуйтесь. А вот Эльбрусов как раз нет, ибо Тайвань больше не хочет их печатать.
А почему гнаться, МЦСТ никто не предлагает сейчас, осваивать другую архитектуру. Но как простите, вы представляете себе конкуренцию с ARM и RISC-V. Сегодня это существование устройств во всех нишах, где-то сейчас и они не слишком конкурентны, но это расширение номенклатуры не обходится дорого. Во все эти ниши, пытаться воткнуть архитектуру Эльбруса? Ну пусть пробуют, у них есть возможность менять архитектуру как им угодно. Но вот RISC-V приходит в ниши ARM, благодаря схожести устройств, и снимает зависимость разработчиков от лицензиара. Не так давно ещё, RISC-V был нишевым, но "засуха чипов" привела к тому, что множество ARM чипов подорожали, особенно в сегменте дешевых микроконтроллеров, и в ней появилось множество новых. Собственно в этом плане, существование Эльбруса на рынке, как раз под вопросом. Может он быть хоть в каком-то классе устройств, дешевле других? Разве что там, где под требования нет других. Вопрос массового производства, ключевой для единственной архитектуры на рынке. А оно в свою очередь, не будет востребовано с одной стороны пока его нет, с другой, пока нет массовой разработки. Без возможностей ко второму, нет смысла создавать не востребованное массовое производство. При этом стоит посмотреть на рынок. Там множество архитектур, некоторые заняты теми, куда Эльбрус мог бы с нынешней номенклатурой войти, но в то же время, ПО для ARM/RISC V, чаще менее платформозависимо и открыто, что и для Эльбруса полезно. @@user-ks5rj3cl2u
