В порядке придирок: PDP-11 -- не модель, а целое семейство программно совместимых машин, т.е., по сути, архитектура. А моделей там было весьма и весьма прилично -- что от самой DEC, что от подражателей, включая СССР (СМ-3, СМ-4, СМ-1300, СМ-1420, СМ-1600 и др.).
Ну, вообще-то самое понятие "архитектура" подразумевает программную совместимость -- по меньшей мере, "снизу вверх". Если прогу, написанную для 32-разрядного RISC-V, можно без перекомпиляции запустить на 64-разрядном, тогда можно считать их одной архитектурой, если нет -- то нет. (Я с RISC-V реально не знаком, поэтому и говорю про "если")
Ну а если сравнить с тем же ARMом одинаковой разрядности, то с одной стороны имеем M-профиль, а с другой -- A- и R-. Хотя почти все собственно команды из M-профиля будут нормально выполняться на процах A- или R-профиля, считать эти разновидности одной архитектурой, как по мне, всё же неправильно: у них кардинально отличается, так сказать, системная архитектура -- в первую очередь, обработка прерываний, и соответствующий код абсолютно непереносим. С другой стороны, A- и R-профили можно считать одной архитектурой: основная разница -- наличие MMU (A) или MPU (R). Ну а 64-разрядная архитектура ARM, понятно, имеет к M-профилю ещё меньшее отношение.
В общем, подозреваю, что с RISC-V примерно так же, как и с ARM: типа одна архитектура, а реально -- несколько, имеющих как общие, так и кардинально различающиеся элементы. Но, как уже сказал, пока в этом вопросе некомпетентен.
Причина 1. Если роцессор работает на ядрах разной битности
Во-первых, очепятка в этом подзаголовке :)
А во-вторых, правильней говорить всё ж о разных архитектурах, а не "битности" (разрядности). Например, в STM32MP15x имеется одно или два 32-разрядных ядра Cortex-A7 и одно 32-разрядное ядро Cortex-M4. "Битности" совпадают, но архитектуры-то реально разные (ARMv7-A и ARMv7-M).
Верное замечание, хотя стоит заметить, что выбор десятичной системы для ЭНИАКа был таки явной ошибкой. Ну и полупроводниковые диоды в его конструкции тоже использовались.
Плюс, с надёжностью ламп отнюдь не всё так однозначно. Они, конечно, перегорают, но это происходит почти всегда в первые несколько (десятков) часов работы, после чего лампа длительное время работает вполне себе надёжно.
Ну, можно быть вполне успешным программистом почти во всех областях и при этом не знать, что машина работает в двоичной, а не десятичной системе... Но, как по мне, действительно хороший специалист всё ж разбирается и в смежных со своей прямой специальностью вещах, да и свою знает глубже, чем необходимо чисто для работы.
Понятно, что это перевод, но несколько замечаний всё ж выскажу.
1) Можно было бы показать формирование отрицательных значений на примере счётчика, считающего задом наперёд. Например, для 4-битового числа 0 = 0000, -1 = 1111, -2 = 1110 и т.д.
2) Обратный код "в древности" использовался довольно часто, но не потому что он проще для железа -- он, напротив, сложнее, почему от него, в конечном итоге, и отказались (при операциях с целыми числами, в вещественной арифметике используется именно он, но там -- уже совсем другая песня). Вероятно, автор статьи не задумывался о том, что в реальном железе для формирования дополнительного кода никакого отдельного сумматора не требуется: прибавление единицы осуществляется путём подачи нужного значения входного переноса на основной сумматор (чтобы выполнить операцию A - B, на сумматор подаётся инверсное значение операнда B и инверсное же значение входного переноса).
3) Можно было бы упомянуть про обнаружение переполнения (флажок V в большинстве процессорных архитектур, хотя в IA-32 aka x86 это флажок OF): технически этот признак формируется путём выполнения операции "исключающее или" между значениями выходного переноса из старшего (знакового) разряда и входного переноса в этот же разряд -- т.е. схема тоже очень проста. Правда, в классическом АЛУ SN74181 (у нас -- К155ИП3) переполнение почему-то не обнаруживается, поэтому там приходится городить внешнюю схему.
Более того, она даже из "чего" способна комбинировать, но не способна понимать, что реально делает, а посему и результаты получаются... сильно разные. В общем, никакого интеллекта у нейросетей нет.
Как уже отметили, предупреждений в проектах очень много, но, в отличие от обычного программирования, от них невозможно избавиться. Скажем, если пишешь на це++ и у тебя вылетает предупреждение, ты вполне можешь проверить не понравившееся компилятору место и внести ту или иную корректировку. А с HDLами -- облом-с :( И в результате пустопорожних предупреждений появляется море, в котором тонут редкие реально важные.
Я сравниваю архитектуры, а не конкретные реализации. Разницу видите? Да и с разными эпохами как-то не очень. Скажем, и PDP-11, и VAX-11, и 8086 -- это 1970-е годы, а z/Architecture -- точно такая же современность, как современные процессоры Интел и АМД.
Только надо не забывать, что все эти бенчмарки нередко "оптимизируют", чтобы показать преимущество над конкурентом, в то время как в реальных приложениях результаты могут быть... иными.
Во-первых, я не сравниваю RISC с CISC, как делают в той статье. Я сравниваю отвратительный CISC (IA-32) с хорошими CISCами (PDP-11, VAX-11, System/360,370...z/Architecture).
Во-вторых, производительность может сильно зависеть от задачи. Скажем, если тебе нужно массовое шифрование или там преобразование из UTF-8 в UTF-32 и другие весьма распространённые, но не совсем уж тривиальные стандартные операции, то в z/Architecture это выполняется одной командой -- что при прочих равных прилично быстрей чисто программной реализации. (Может, кстати, поддержку подобных вещей и в IA-32 добавили: я особо за ним не слежу.) Ну а на каких-нибудь "графических" задачах даже посредственный GPU уделает любой центральный процессор "обычной" архитектуры, хотя безнадёжно ему сольёт на "задаче общего назначения", где нет возможности массово распараллеливать потоки данных.
Ну а в-третьих, есть ещё вопрос энергоэффективности. Интеловский Атом как основа для мобильных платформ, как известно, составить реальную конкуренцию ARMу не смог -- не в последнюю очередь из-за дикой сложности системы команд и её кодирования, для реализации чего требуется куча железа (которое жрёт кучу энергии). При этом собственно вычислительные блоки у процессоров одинаковы: математика -- она и в Африке математика, и её реализация не зависит от системы команд как таковой.
Кстати говоря, у современных ARMов от RISC мало что осталось -- по сути, лишь выполнение операций обязательно в регистрах (нет команд "регистр-память" и "память-память"). Это косвенно доказывает порочность самой идеи RISC (максимально простая система команд), если речь заходит от необходимости получить сколько-нибудь приличную производительность. Конкретно в 1980-е и в начале 1990-х RISCи имели более высокую производительность по той причине, что их можно было реализовать в рамках одной микросхемы, а CISCи туда не очень-то лезли (можно вспомнить математические сопроцессоры 8087...80487, хотя у части 80486 эти команды были таки уже реализованы в одном кристалле с основным процессором). Но по мере увеличения доступного количества транзисторов на одном кристалле это преимущество было утрачено, что, собсно, Интел и АМД и демонстрируют, реализуя высокопроизводительные процессоры даже для отвратительной системы команд, хотя и ценой большой сложности и большого потребления энергии.
Вот производительность как раз и получается кошмарная, и с экономией ресурсов тоже огромные напряги: чем сложнее кодирование, тем труднее декодировать. Ну а про CP/M я тоже написал: она была создана для 8-разрядных компьютеров, и сегментация ей даром была не нужна.
Вообще-то, CP/M делалась для 8-разрядных процов и благополучно работала на том же 8080. Сегментные регистры им понадобились, чтобы расширить физическое адресное пространство до 1 Мбайта с 64 Кбайт. И если в 8086 это ещё можно понять (хотя Zilog в Z8000 сделала куда разумнее, ну а раньше это было сделано DECом в PDP-11 -- тоже 16-разрядных, но с физическим адресом в зависимости от модели в 16, 18 или 22 разряда, и с довольно специфическим, но удобным в использовании MMU), то в 80286... Если уж вводите защиту памяти, то вводите по-человечески, а не через задницу. Собственно, по-человечески и пришлось сделать -- но в 80386.
Но претензии далеко не только в сегментации. Сама система команд ужасна, а её кодировка -- это вообще нечто... В частности, нет никакого простого способа определить длину кода команды -- приходится байт за байтом его анализировать. Ну и сравните это и с Системой 360, и с той же PDP-11, где длина команды однозначно устанавливается из её первого полуслова (Система 360) / слова (PDP-11; в обоих случаях это 2 байта), а сама команда всегда состоит из 2, 4 или 6 байтов. И всё это дерьмо приходится тащить ради совместимости...
Само появление сегментации, как и целая куча других особенностей интеловской архитектуры, является бредом. Они ухитрились собрать практически все возможные грабли в плане архитектуры -- причём сделали это уже в 1970-80-х годах, а не в 1950-60-х, когда опыт только нарабатывался (да и само понятие "архитектура" и её отделение от конкретной реализации появилось лишь в IBMовской Системе 360, а это 1964-й). Ну а что дальше приходится тянуть совместимость -- оно понятно...
Следить за каждым байтом памяти в отдельности было бы накладно, по-этому ядро оперирует достаточно большими блоками памяти - страницами, типовой размер которых составляет 4 килобайта
Ядро оперирует страницами не потому, что следить за каждым байтом накладно, а потому что аппаратура управления памятью (MMU) отображает виртуальные адреса на реальные, в конечном счёте, именно страницами, а не отдельными байтами. И, кстати говоря, размер страницы вовсе не обязан быть равен 4 Кбайтам -- это, как минимум, зависит от возможностей аппаратуры.
Также стоит упомянуть, что на аппаратном уровне как правило есть поддержка дополнительного уровня абстракции в виде "сегментов" оперативной памяти, с помощью которых можно разделять программы на части. В отличии от других операционных систем, в Linux она практически не используется - логический адрес всегда совпадает с линейным (адресом внутри сегмента, которые сконфигурированы фиксированным образом).
Во-первых, сегментация -- отличительная фишка архитектуры IA-32 aka x86, доступная в 16- и 32-разрядных режимах, но выпиленная из 64-разрядного режима. У других архитектур такого бреда мне не встречалось (хотя, возможно, альтернативно одарённые архитекторы подвизаются не только в Интел).
Во-вторых, сегментацией практически никто никогда не пользовался с момента появления 80386. В частности, ей никогда не пользовались в 32-разрядных версиях Винды.
Ну и т.д. и т.п. В общем, как обычно: списано у других без особого понимания материала.
Только почему до сих пор Verilog? Уже, пожалуй, все средства разработки под ПЛИС поддерживают SystemVerilog, а он имеет изрядное число преимуществ, и не только для верификации, но и для синтеза. В частности, используя вместо always специализированные always_ff, always_latch, always_comb, можно сказать компилятору, что ты хочешь получить, и это поможет избежать неявных ошибок.
В принципе, может. Но обычно такой возможностью не пользуются (и я не знаю, где это возможно, кроме OS/360 с её MODESET). Плюс, ещё в каком адресном пространстве находится исполняемый код (у OS/360 тут тоже неоднозначно: изрядная часть системного по своей сути кода, насколько помню, грузилась в разделы задач пользователей).
Вероятно, изначально речь была об отсутствии серийных поставок -- типа, только инженерные образцы.
В порядке придирок: PDP-11 -- не модель, а целое семейство программно совместимых машин, т.е., по сути, архитектура. А моделей там было весьма и весьма прилично -- что от самой DEC, что от подражателей, включая СССР (СМ-3, СМ-4, СМ-1300, СМ-1420, СМ-1600 и др.).
"Определите, какой ресурс вы хотите управлять"
И так несколько раз. У автора проблемы с использованием падежей?...
Приличное количество ошибок в плане русского языка не есть хорошо.
Приличное количество смех**чков уместно (и даже прямо требуется) на лурке, но не на хабре.
Геометрические шейдеры появились в DirectX 10, а не 9.
Ну, вообще-то самое понятие "архитектура" подразумевает программную совместимость -- по меньшей мере, "снизу вверх". Если прогу, написанную для 32-разрядного RISC-V, можно без перекомпиляции запустить на 64-разрядном, тогда можно считать их одной архитектурой, если нет -- то нет. (Я с RISC-V реально не знаком, поэтому и говорю про "если")
Ну а если сравнить с тем же ARMом одинаковой разрядности, то с одной стороны имеем M-профиль, а с другой -- A- и R-. Хотя почти все собственно команды из M-профиля будут нормально выполняться на процах A- или R-профиля, считать эти разновидности одной архитектурой, как по мне, всё же неправильно: у них кардинально отличается, так сказать, системная архитектура -- в первую очередь, обработка прерываний, и соответствующий код абсолютно непереносим. С другой стороны, A- и R-профили можно считать одной архитектурой: основная разница -- наличие MMU (A) или MPU (R). Ну а 64-разрядная архитектура ARM, понятно, имеет к M-профилю ещё меньшее отношение.
В общем, подозреваю, что с RISC-V примерно так же, как и с ARM: типа одна архитектура, а реально -- несколько, имеющих как общие, так и кардинально различающиеся элементы. Но, как уже сказал, пока в этом вопросе некомпетентен.
Причина 1. Если роцессор работает на ядрах разной битности
Во-первых, очепятка в этом подзаголовке :)
А во-вторых, правильней говорить всё ж о разных архитектурах, а не "битности" (разрядности). Например, в STM32MP15x имеется одно или два 32-разрядных ядра Cortex-A7 и одно 32-разрядное ядро Cortex-M4. "Битности" совпадают, но архитектуры-то реально разные (ARMv7-A и ARMv7-M).
Верное замечание, хотя стоит заметить, что выбор десятичной системы для ЭНИАКа был таки явной ошибкой. Ну и полупроводниковые диоды в его конструкции тоже использовались.
Плюс, с надёжностью ламп отнюдь не всё так однозначно. Они, конечно, перегорают, но это происходит почти всегда в первые несколько (десятков) часов работы, после чего лампа длительное время работает вполне себе надёжно.
Ну, можно быть вполне успешным программистом почти во всех областях и при этом не знать, что машина работает в двоичной, а не десятичной системе... Но, как по мне, действительно хороший специалист всё ж разбирается и в смежных со своей прямой специальностью вещах, да и свою знает глубже, чем необходимо чисто для работы.
Понятно, что это перевод, но несколько замечаний всё ж выскажу.
1) Можно было бы показать формирование отрицательных значений на примере счётчика, считающего задом наперёд. Например, для 4-битового числа 0 = 0000, -1 = 1111, -2 = 1110 и т.д.
2) Обратный код "в древности" использовался довольно часто, но не потому что он проще для железа -- он, напротив, сложнее, почему от него, в конечном итоге, и отказались (при операциях с целыми числами, в вещественной арифметике используется именно он, но там -- уже совсем другая песня). Вероятно, автор статьи не задумывался о том, что в реальном железе для формирования дополнительного кода никакого отдельного сумматора не требуется: прибавление единицы осуществляется путём подачи нужного значения входного переноса на основной сумматор (чтобы выполнить операцию A - B, на сумматор подаётся инверсное значение операнда B и инверсное же значение входного переноса).
3) Можно было бы упомянуть про обнаружение переполнения (флажок V в большинстве процессорных архитектур, хотя в IA-32 aka x86 это флажок OF): технически этот признак формируется путём выполнения операции "исключающее или" между значениями выходного переноса из старшего (знакового) разряда и входного переноса в этот же разряд -- т.е. схема тоже очень проста. Правда, в классическом АЛУ SN74181 (у нас -- К155ИП3) переполнение почему-то не обнаруживается, поэтому там приходится городить внешнюю схему.
4) А почему код называется дополнительным? ;)
Более того, она даже из "чего" способна комбинировать, но не способна понимать, что реально делает, а посему и результаты получаются... сильно разные. В общем, никакого интеллекта у нейросетей нет.
Как уже отметили, предупреждений в проектах очень много, но, в отличие от обычного программирования, от них невозможно избавиться. Скажем, если пишешь на це++ и у тебя вылетает предупреждение, ты вполне можешь проверить не понравившееся компилятору место и внести ту или иную корректировку. А с HDLами -- облом-с :( И в результате пустопорожних предупреждений появляется море, в котором тонут редкие реально важные.
Я сравниваю архитектуры, а не конкретные реализации. Разницу видите? Да и с разными эпохами как-то не очень. Скажем, и PDP-11, и VAX-11, и 8086 -- это 1970-е годы, а z/Architecture -- точно такая же современность, как современные процессоры Интел и АМД.
Только надо не забывать, что все эти бенчмарки нередко "оптимизируют", чтобы показать преимущество над конкурентом, в то время как в реальных приложениях результаты могут быть... иными.
Во-первых, я не сравниваю RISC с CISC, как делают в той статье. Я сравниваю отвратительный CISC (IA-32) с хорошими CISCами (PDP-11, VAX-11, System/360,370...z/Architecture).
Во-вторых, производительность может сильно зависеть от задачи. Скажем, если тебе нужно массовое шифрование или там преобразование из UTF-8 в UTF-32 и другие весьма распространённые, но не совсем уж тривиальные стандартные операции, то в z/Architecture это выполняется одной командой -- что при прочих равных прилично быстрей чисто программной реализации. (Может, кстати, поддержку подобных вещей и в IA-32 добавили: я особо за ним не слежу.) Ну а на каких-нибудь "графических" задачах даже посредственный GPU уделает любой центральный процессор "обычной" архитектуры, хотя безнадёжно ему сольёт на "задаче общего назначения", где нет возможности массово распараллеливать потоки данных.
Ну а в-третьих, есть ещё вопрос энергоэффективности. Интеловский Атом как основа для мобильных платформ, как известно, составить реальную конкуренцию ARMу не смог -- не в последнюю очередь из-за дикой сложности системы команд и её кодирования, для реализации чего требуется куча железа (которое жрёт кучу энергии). При этом собственно вычислительные блоки у процессоров одинаковы: математика -- она и в Африке математика, и её реализация не зависит от системы команд как таковой.
Кстати говоря, у современных ARMов от RISC мало что осталось -- по сути, лишь выполнение операций обязательно в регистрах (нет команд "регистр-память" и "память-память"). Это косвенно доказывает порочность самой идеи RISC (максимально простая система команд), если речь заходит от необходимости получить сколько-нибудь приличную производительность. Конкретно в 1980-е и в начале 1990-х RISCи имели более высокую производительность по той причине, что их можно было реализовать в рамках одной микросхемы, а CISCи туда не очень-то лезли (можно вспомнить математические сопроцессоры 8087...80487, хотя у части 80486 эти команды были таки уже реализованы в одном кристалле с основным процессором). Но по мере увеличения доступного количества транзисторов на одном кристалле это преимущество было утрачено, что, собсно, Интел и АМД и демонстрируют, реализуя высокопроизводительные процессоры даже для отвратительной системы команд, хотя и ценой большой сложности и большого потребления энергии.
Вот производительность как раз и получается кошмарная, и с экономией ресурсов тоже огромные напряги: чем сложнее кодирование, тем труднее декодировать. Ну а про CP/M я тоже написал: она была создана для 8-разрядных компьютеров, и сегментация ей даром была не нужна.
Вообще-то, CP/M делалась для 8-разрядных процов и благополучно работала на том же 8080. Сегментные регистры им понадобились, чтобы расширить физическое адресное пространство до 1 Мбайта с 64 Кбайт. И если в 8086 это ещё можно понять (хотя Zilog в Z8000 сделала куда разумнее, ну а раньше это было сделано DECом в PDP-11 -- тоже 16-разрядных, но с физическим адресом в зависимости от модели в 16, 18 или 22 разряда, и с довольно специфическим, но удобным в использовании MMU), то в 80286... Если уж вводите защиту памяти, то вводите по-человечески, а не через задницу. Собственно, по-человечески и пришлось сделать -- но в 80386.
Но претензии далеко не только в сегментации. Сама система команд ужасна, а её кодировка -- это вообще нечто... В частности, нет никакого простого способа определить длину кода команды -- приходится байт за байтом его анализировать. Ну и сравните это и с Системой 360, и с той же PDP-11, где длина команды однозначно устанавливается из её первого полуслова (Система 360) / слова (PDP-11; в обоих случаях это 2 байта), а сама команда всегда состоит из 2, 4 или 6 байтов. И всё это дерьмо приходится тащить ради совместимости...
Само появление сегментации, как и целая куча других особенностей интеловской архитектуры, является бредом. Они ухитрились собрать практически все возможные грабли в плане архитектуры -- причём сделали это уже в 1970-80-х годах, а не в 1950-60-х, когда опыт только нарабатывался (да и само понятие "архитектура" и её отделение от конкретной реализации появилось лишь в IBMовской Системе 360, а это 1964-й). Ну а что дальше приходится тянуть совместимость -- оно понятно...
Графоманство продолжается. Навскидку:
Следить за каждым байтом памяти в отдельности было бы накладно, по-этому ядро оперирует достаточно большими блоками памяти - страницами, типовой размер которых составляет 4 килобайта
Ядро оперирует страницами не потому, что следить за каждым байтом накладно, а потому что аппаратура управления памятью (MMU) отображает виртуальные адреса на реальные, в конечном счёте, именно страницами, а не отдельными байтами. И, кстати говоря, размер страницы вовсе не обязан быть равен 4 Кбайтам -- это, как минимум, зависит от возможностей аппаратуры.
Также стоит упомянуть, что на аппаратном уровне как правило есть поддержка дополнительного уровня абстракции в виде "сегментов" оперативной памяти, с помощью которых можно разделять программы на части. В отличии от других операционных систем, в Linux она практически не используется - логический адрес всегда совпадает с линейным (адресом внутри сегмента, которые сконфигурированы фиксированным образом).
Во-первых, сегментация -- отличительная фишка архитектуры IA-32 aka x86, доступная в 16- и 32-разрядных режимах, но выпиленная из 64-разрядного режима. У других архитектур такого бреда мне не встречалось (хотя, возможно, альтернативно одарённые архитекторы подвизаются не только в Интел).
Во-вторых, сегментацией практически никто никогда не пользовался с момента появления 80386. В частности, ей никогда не пользовались в 32-разрядных версиях Винды.
Ну и т.д. и т.п. В общем, как обычно: списано у других без особого понимания материала.
Только почему до сих пор Verilog? Уже, пожалуй, все средства разработки под ПЛИС поддерживают SystemVerilog, а он имеет изрядное число преимуществ, и не только для верификации, но и для синтеза. В частности, используя вместо always специализированные always_ff, always_latch, always_comb, можно сказать компилятору, что ты хочешь получить, и это поможет избежать неявных ошибок.
В принципе, может. Но обычно такой возможностью не пользуются (и я не знаю, где это возможно, кроме OS/360 с её MODESET). Плюс, ещё в каком адресном пространстве находится исполняемый код (у OS/360 тут тоже неоднозначно: изрядная часть системного по своей сути кода, насколько помню, грузилась в разделы задач пользователей).