Комментарии 18
Вообще-то, 8086/88, будучи 16-разрядными, могли адресовать 1 Мбайт памяти. А ИБМовская Система 360, будучи 32-разрядной, могла адресовать только 16 Мбайт памяти. А 16-разрядная PDP-11 в зависимости от варианта -- 64 Кбайта, 256 Кбайт или 4 Мбайта. Дело в том, что адрес не обязательно совпадает с разрядностью процессора -- в т.ч. логический (виртуальный) адрес, а о физическом и говорить нечего.
Да, вы правы, спасибо! Решил и вовсе убрать информацию об этом, так как для целей этой статьи она избыточна
Кстати, ещё про разрядность. Одно дело разрядность с точки зрения программиста, и другое -- физическая разрядность. Одно с другим тоже не очень-то связаны. Разрядность с точки зрения программиста определяется архитектурой (скажем, IA-32 -- 32-разрядная, а её расширение до AMD64 дало в результате современную 64-разрядную архитектуру). А вот физическая определяется разработчиками проца исходя из требований к производительности и т.п. Сейчас они если не всегда, то почти всегда совпадают, но это не является безусловно необходимым. Скажем, Система 360 -- 32-разрядная, однако её процессоры внутри были и 8-, и 16-, и 32-, и 64-разрядными в зависимости от производительности конкретной модели.
но не против конструктивной критики.
Возьмем картинки:
на первой картинке кэш L3 находится справа, а ядра - слева. На второй наоборот, что мгновенно сбивает читателя;
на обеих картинках смешан русский и английский язык, а в тексте используются русские слова без перевода, таким образом для читателя это превращается в терминологическую кашу;
на обеих картинках заглавные и строчные буквы в написании слов применяются бессистемно.
Возьмем текст: выделение жирным используется поначалу для описания терминов, далее для описания действий этих терминов, а потом вообще непонятно для чего.
Вследствие совокупной небрежности, воспринимать этот текст сложно, а в вырванных из контекста фразах вообще сложно понять смысл:
Инструкции, которые передаются вместе с данными, попадают в кэш инструкций, а данные оказываются в кэше данных.
А что происходит с инструкциями, которые передаются отдельно о данных? Или так не бывает? И в чем вообще смысл разделять их, инструкции это разве не данные, а что это тогда? И что такое кэш, в который надо "попадать"?
Спасибо за замечения! Смешно получилось с сочетанием языков на картинках, как в меме: "смотря какие details"))))
Ну а вообще, изначально такая асимметрия в картинках из-за более привычного расположения ОЗУ справа от ЦП, но при этом при просмтре строения ядра привычнее читать схему слева направо. С учётом схематичности изображений, а также с разнообразности строения материнских плат, особенно серверных, решил поменять картинки, чтобы всё читалось слева направо.
Быстродействие компьютера определяется тактовой частотой его процессора.
Нет. Быстродействие компьютера определяется множеством факторов. Например, скоростью работы дисковой подсистемы, если вы с файлами работаете. Если же мы хотим упростить быстродействие компьютера до быстродействия процессора, то оно опредляется не только частотой, а ещё и таким показателем как IPC (Instructions per Cycle)
RISC (Reduced Instruction Set Computing)
Преимущества:
Простота инструкций: Инструкции в RISC-архитектуре проще и быстрее выполняются, что позволяет увеличить производительность за счет более быстрого цикла выполнения команд.
Конвейеризация: За счет простоты инструкций конвейеризация (pipelining) становится более эффективной, что позволяет выполнить больше команд за такт.
Энергоэффективность: Меньшее количество транзисторов и простота инструкций обычно приводят к более низкому энергопотреблению, что важно для мобильных и встроенных устройств.
Универсальность: Простые инструкции легко реализуются в аппаратуре, что делает архитектуру более гибкой для различных типов приложений.
В современном мире все приведённые преимущества неверны.
Недостатки:
Сложности компиляции: Компиляторы должны быть более умными, чтобы эффективно использовать простые инструкции для сложных задач.
Скажем так, в современном мире это тоже не так.
CISC (Complex Instruction Set Computing)
Преимущества:
Многофункциональность: Поддержка множества инструкций и режимов работы позволяет процессорам x86-64 быть очень универсальными и адаптивными для разных задач.
Это не так. Современные RISC процессоры ничем в этом аспекте не уступают. Вы же тут сами себе противоречите, где в преимуществах RISC называете универсальность.
Недостатки:
Сложность и энергопотребление: Более сложные инструкции требуют больше транзисторов и более сложной логики, что увеличивает энергопотребление и тепловыделение.
Наследие: Поддержка устаревших инструкций и режимов может накладывать дополнительные ограничения на архитектуру, делая ее менее эффективной по сравнению с RISC.
Это тоже в современном мире неверно. Это вообще странно писать в ситуации, когда самые высокопроизводительные процессоры на текущий момент - CISC процессоры архитектуры x86.
самые высокопроизводительные процессоры на текущий момент - CISC процессоры архитектуры x86
Вообще, от задачи зависит. Скажем, в роли матричной числодробилки даже посредственный графический процессор порвёт любой AMD64. Если всякие там массовые шифрования AES и всё такое прочее, то, вполне возможно, победителем будет проц z/Architecture, где подобные операции делаются одной командой (и он, есно, CISC, ведущий свою родословную от Системы 360). Но, в любом случае, проблематично назвать "самый-самый", а уж без конкретизации рода задач -- и вовсе невозможно.
Можно придраться ко многим фразам, но, раз уж название "для самых маленьких", то сойдёт.
Однако вывод просто противоречит фактам и мимо него нельзя просто пройти, проигнорировав. Например, в том, что достигнув производительности десктопных х86, arm по tdp и энергоэффективности сравнялись с x86. С другой стороны, Intel выпустила линейку процессоров Lunar Lake, спроектированную под тонкие, лёгкие и автономноые ультрабуки. И это у них получилось. Lunar Lake по производительности выступают на равных или быстрее соответствующих чипов Qualcomm и Apple, превосходя их по энергоэффективности.
Рано хоронить х86.
Вероятно, автор хоронит их на фоне актуальных проблем Intel.
Вы правы, хоронить точно рано!
Но и так же точно мы дожили до момента, когда процессоры для мобильников стали конкурентами ноутбучных x86. Самый главный звоночек в сторону улучшений ситуации с ARM является то, что AMD объединилась с Intel против ARM. А здоровая конкуренция точно нам всем на руку! В удивительное время живём)
Хранит базовый адрес сегмента кода в ОЗУ
Не адрес, а селектор. А селектор (в защищённом режиме) это флаговые биты плюс индекс в таблице — таблице дескрипторов сегментов.
И уже в дескрипторе сегмента хранится базовый адрес сегмента.
так как открыл путь к полноценной поддержке многозадачности
А чем неполноценна многозадачность в 286? В 386 в плане многозадачности появился только режим Virtual 8086 mode. Остальные новые фишки касаются в основном MMU, например, введение страничной организации и дополнительного уровня трансляции адресов (линейных) в физические.
Довольно многие, как я заметил, путают виртуальную память с многозадачностью -- хотя эти вещи вообще ни разу не связаны. Многозадачность возможна на системах вообще без защиты памяти, не говоря уже о поддержке её виртуализации. И наоборот, можно слепить однозадачную систему с виртуальной памятью.
Ещё больший процент не знают и не понимает концепцию сегментов в защищенном режиме, имея представление о сегментах на основе сегментов реального режима :-(
Ну, для этого нужно погружаться конкретно в 8086, 80286 и IA-32 (80386 и далее): эта фишка -- их черта, а в подавляющем большинстве процессорных архитектур такого нет. (Слово "сегмент" может использоваться, но имеет совершенно другой смысл; скажем, в Системе 370 сегменты -- это верхний уровень деления виртуальной памяти на блоки, нижний уровень -- страницы; управляющий регистр процессора указывает адрес таблицы сегментов, в элементах таблицы сегментов содержатся адреса таблиц страниц, а уже в элементах таблиц страниц -- реальные адреса страниц в памяти.)
Ну и, Вам, не сомневаюсь, известно (а вот многим другим -- не очень), что, хотя в IA-32 сегментация является обязательной, но сегменты настраиваются таким образом, что получается не сегментированное, а плоское виртуальное адресное пространство -- т.е., по сути, сегментация в сколько-нибудь массовых ОС, включая Винду и Линух, не используется, хотя технически имеется (а в AMD64 её по этой причине и выпилили). Интересно, во всяких "танненбаумах" или что там используется в учебном процессе по осям, про неё сколько-нибудь внятно говорится?..
т.е., по сути, сегментация в сколько-нибудь массовых ОС, включая Винду и Линух, не используется
Но это не совсем так.
Windows в user-mode создаёт небольшой сегмент с базой, указывающей на thread environment block (TEB) / thread information block (TIB), а селектор этого сегмента загружает в регистр FS.
Отсюда обращения к FS:[0] для работы с SEH-цепочкой, работа виндового TLS на это завязано, да и куча кода в kernel32.dll и иже с ними лежет в TEB для множества разных целей.
В Linux-е FS используется для TLS, а GS доступен для использования.
В этом объёме сегментацию не выпилили даже в AMD64.
Но в целом, тот факт, что Intel предложила миру эту классную концепцию, а её в полной мере никто не заценил и не использовал, вызывает у меня моральные страдания. У меня даже есть мысль написать статью о том, каким мог бы быть мир, если бы сегменты использовали в хвост и в гриву (в защищённом режиме и 32-битном режиме).
Да, может постоянная замена значения сегментных регистров и вызвала бы проблемы с производительностью (из-за необходимости процессора обращаться к таблицам дескрипторов, чтобы занести что-то в теневую часть сегментных регистров), но уверен, Intel могла это красиво оптимизировать, будь на технологию ответный спрос, как она оптимизировала трансляцию линейных адресов в физические (речь о TLB).
Подумать только: у нас был бы мир с аппаратной защитой от ошибки переполнения буфера, мир, где программу можно было бы разбить на множество изолированных друг от друга микро-песочниц, где функция не могла бы из себя вызвать какую угодно другую функцию процесса и обратиться к каким угодно другим данным процесса, а «видела» бы только минимально необходимый для своей работы набор данных и других функций/процедур. Ошибки переполнения буфера, шеллкод и инжект перестали бы существовать или потеряли бы смысл...
Но это не совсем так.
Windows в user-mode создаёт небольшой сегмент с базой, указывающей на thread environment block (TEB) / thread information block (TIB), а селектор этого сегмента загружает в регистр FS.
Отсюда обращения к FS:[0] для работы с SEH-цепочкой, работа виндового TLS на это завязано, да и куча кода в kernel32.dll и иже с ними лежет в TEB для множества разных целей.
В Linux-е FS используется для TLS, а GS доступен для использования.
Я в курсе про это. Но реально сие использование сегментации -- совсем не такое, как задумывалось создателями архитектуры. По сути, FS и GS используются как дополнительные базовые регистры -- как можно использовать, например, EBX -- ведь они задают положение некоей области в едином плоском виртуальном адресном пространстве. В таком качестве они используются и в AMD64, где сегментация как таковая выпилена полностью. В общем, это довольно остроумное извлечение пользы из, скажем так, малоудачного аппаратного механизма, который сам по себе никому не нужен.
Кстати, потенциально сегментацию можно было бы использовать для относительно эффективной реализации по-настоящему микроядерной ОС, но и там он... слишком заумный и не особо эффективный. Лично мне больше нравится механизм множества адресных пространств у IBMовских мэйнфреймов (стал появляться в поздних вариантах Системы 370 и в дальнейшем развивался; правда, используется не в собственно ОС, а для реализации серверов приложений или чего-то в этом роде).
/del
Публикации
Мои заметки про процессоры для cовсем маленьких