01. Принципы развития архитектур ЭВМ; система команд RISC-V

[@qa337]

Наконец-то нормальная рекомендация от ютуба. Подписался!

[@fnav8593]

отличная лекция! Спасибо за интересные объяснения

[@gameplay-ld6ch]

Спасибо большое за курс

[@hussur]

Ранние ЭВМ это "последовательное исполнение команд" (in order execution) Позднее придумали раздробить исполнение команд на стадии (pipeline) что бы позволить независимым инструкциям запускаться не дожидаясь завершения предыдущей. Примерно в это же время примерно для таких же целей придумали superscalar - исполнение независимых инструкций параллельно на разных юнитах. Еще позже добавили к этому Out-of-order - то есть выявление независимых инструкций в буфере команд и исполнение их вне очереди. Все подходы дополняют друг друга и оказывают синергитический эффект и в современных высокопроизводительных процессорах являются обязательными к реализации, хотя и без проблем то же не обошлось. Как бы там нибыло это все было во времена когда быстрые программы писали только на ассемблере и ассемблер был сделан так, что бы быть удобным для программирования (CISC). Когда языки высокого уровня (например Си) начали вытеснять ассемблер, народ задумался о том что бы сделать машинный язык проще для исполнения (RISC) максимально приблизив его к микрооперациям. Третьи вообще предложили что раз пошла такая пляска в сторону упрощения тогда надо и другие костыли выкидывать и генерировать сразу параллельный код для исполнения. (VLIW) Последняя идея вспоткнулась об то, что для того что бы генерировать качественный параллельный код надо знать что у пользователя за железо и как именно он собирается эксплуатировать софт. В специализированных вычислителях где заранее известно какая программа и с какими данными будет работать - это отлично себя зарекомендовало. В десктопном же софте где программист пишет софт на все случаи жизни, маинтейнер собирает это все под условное железо, а пользователь использует 1% функционала от этого всего, реалии понятное дело другие, статически тут не подстроишься. Но все постепенно меняется, 3d графика уже давно пришла к незаметной компиляции шейдеров перед запуском для более эффективного использования железа, раст постепенно к этому же подбирается, ускорять программы засчет железа уже некуда

[@FrBrGeorge]

Спасибо, лаконичный и вполне понятный roadmap любого курса по АЭ. Я бы ещё добавил туда в качестве постоянной напоминалки феномен legacy: ситуацию, когда некоторая техническая задача решена столько-то десятилетий назад, но в силу разных причин решать её по-новому пока не хотят, а вместо этого изобретают костыли.

[@DigitalEvolutionRU]

Когда говорят Фонейманская архитектура тогда подразумевают что есть ещё другая архитектура - Гарвордская. Отличие архитектур состоит в том что Фонейманской архитектуре есть общее пространство памяти для данных и команд (то есть команды могут выступать как данные и наоборот данные как команды например Intel8086) , а в Гарвардской архетиктуре область программ и данных разделены( например PIC12F1840). То есть при каком либо сбое в Гарвардской архетектуре невозможен программный переход на область данных поэтому предполагается как боллее надежная.

[@gennadyz7699]

И менее гибкая))

[@empty128]

Если смотреть нудно и скучно то выставите скорость воспроизведения 1.25-1.5 видео сразу станет информативным и интересным. 41:08 Утверждение что фиксированная длина инструкций в два раза увеличивает скорость считывания из памяти херня полнейшая. Уже процессор 8086 имел функцию предварительной выборки инструкций из памяти и выполнялся параллельно исполнению инструкций. Эта функция улучшалась во всех последующих процессорах. Можно утверждать что разная длина команд увеличивает транзисторный бюджет но вот утверждение что увеличивает в два раз скорость считывания инструкций из памяти в корне не верно.

[@UNEEX_MSU]

Все сообщённые вами факты - чистая правда. А вот выводы вы из них делаете отчего-то противоположные, да ещё и ругаетесь зачем-то. Вот, в процессоре 8086 изобрели, цитирую, «функцию предварительной выборки инструкций из памяти и выполнялся параллельно исполнению инструкций… улучшалась во всех последующих процессорах». Это модификация архитектуры, местами довольно непростая ещё на 8086 (вы вот отсылаете к «транзисторному бюджету». Которую пришлось сделать почему? Потому что _без неё выборка работала медленно_ - по причине зависимости по данным. Вот и весь разговор. Так-то можно было даже prefetch не делать, просто читать сразу инструкцию максимального размера, и обрезать, если что. Но и это потребовало бы модификации архитектуры. Ну, а в современных x86 процессорах вообще неописуемая толща оптимизаций… думаю, любое утверждение относительно быстродействия какой-либо машинной инструкции окажется, как вы изящно выразились, «полной хернёй».

[@levshx]

надеюсь после этого плейлиста я пойму что такое уровень пользователя и супервизора

[@БорисАверин-в9ф]

"Упаковкой" команд в vliw архитектуре занимается компилятор, ровно так же как это происходит в risc процессорах. Почему-то повышенная трудоёмкость написания программ и сложность компиляторов для risc процессоров вами аккуратно обойдена стороной. Совпадение? Не думаю! ;-) Да и про остальные недостатки risc архитектур вы почему-то умолчали, зато изъяны х86 вы расписали во всех деталях. Попахивает каким-то заказом.

[@UNEEX_MSU]

Не вполне ясно, о какой «повышенной трудоёмкости» и «сложности компиляторов» вы говорите. В случай vliw всё понятно: одна инструкция довольно длинная, нужно представлять граф выполнения в виде зависимостей микроинструкций по данным и управлению, некоторой сложной логикой их переупорядочивать, а затем упаковывать в эти самые длинные инструкции. Любая недоупаковка - проседание производительности (и пузыри в конвейере). А в чем состоит аналогичная сложность для RISC, в которой инструкции, наоборот, заведомо простые и быстрые? Про «заказ» не понял… Вы намекаете на то, что курс называется «Архитектура RISC-V»? Ну так можете не намекать, он действительно так называется ☺

[@dmitryponyatov2158]

архитектуру ЭВМ логичнее на ПЛИСах давать, но объём курса будет просто конский

[@FrBrGeorge]

Да даже оба классических труда - Харрис/Харрис и Паттерсон/Хенесси - каждый в отдельности заведомо конские

[@siarheimarozau6763]

Как мне дороги Линуксоиды. Хотелось бы удавить их еще в колыбели. Они даже не представляют что я (100% виндовс пользователь ) сейчас думаю. А лектор просто написал две строчки кода и программа заработала. И не моргнув глазом пошел дальше!

[@UNEEX_MSU]

Это в вас зависть говорит)

[@Dan.Strelok]

Нах это, когда есть готовый эльбрус? Да и тот же Байкал....

[@UNEEX_MSU]

Вся фишка в RARS-е. Если вы сделаете аналогичный ролик по «Эльбрусу или тому же Байкалу», очень многие, несомненно, будут вам благодарны. Но, боюсь, без эмулятора достаточной степени наглядности это будет довольно затруднительно.

[@Dan.Strelok]

@@UNEEX_MSU ролик то хорош, но я про риск архитектуру, про то что процессора то нет, а Эльбрус то есть, готовый , развивай и распростроняй, зачем делать кучу разных кристаллов разной архитектуры и инструкциями, это как погонишся сразу за всеми зайцами, и не одного не поймаешь.

[@FrBrGeorge]

@@Dan.Strelok процессоров RISC-V десятка два одних только производителей. Например, Western Digital или HiFive - поинтересуйтесь. А вот Эльбрусов как раз нет, ибо Тайвань больше не хочет их печатать.

[@olegstpekar]

А почему гнаться, МЦСТ никто не предлагает сейчас, осваивать другую архитектуру. Но как простите, вы представляете себе конкуренцию с ARM и RISC-V. Сегодня это существование устройств во всех нишах, где-то сейчас и они не слишком конкурентны, но это расширение номенклатуры не обходится дорого. Во все эти ниши, пытаться воткнуть архитектуру Эльбруса? Ну пусть пробуют, у них есть возможность менять архитектуру как им угодно. Но вот RISC-V приходит в ниши ARM, благодаря схожести устройств, и снимает зависимость разработчиков от лицензиара. Не так давно ещё, RISC-V был нишевым, но "засуха чипов" привела к тому, что множество ARM чипов подорожали, особенно в сегменте дешевых микроконтроллеров, и в ней появилось множество новых. Собственно в этом плане, существование Эльбруса на рынке, как раз под вопросом. Может он быть хоть в каком-то классе устройств, дешевле других? Разве что там, где под требования нет других. Вопрос массового производства, ключевой для единственной архитектуры на рынке. А оно в свою очередь, не будет востребовано с одной стороны пока его нет, с другой, пока нет массовой разработки. Без возможностей ко второму, нет смысла создавать не востребованное массовое производство. При этом стоит посмотреть на рынок. Там множество архитектур, некоторые заняты теми, куда Эльбрус мог бы с нынешней номенклатурой войти, но в то же время, ПО для ARM/RISC V, чаще менее платформозависимо и открыто, что и для Эльбруса полезно. @@Dan.Strelok

[@Dan.Strelok]

@@olegstpekar есть Байкал, тот же арм

[@Alexander_Gurov_RF]

Тут большое упущение и историческая несправедливость. Первая 64-битная архитектура MIPS (R4000, ISA v3) появилась ещё в 1992-м году. Широко применялась в игровых консолях Nintendo-64, и Sony Playstation, и не только. Куда там амд64...

[@UNEEX_MSU]

Это правда! Спасибо за замчание!

[@БорисАверин-в9ф]

Красивая сказка.

[@ДимаБочаров-н8ы]

Много воды и сплошные заикания, первая треть сука-скука...