Формально, ни в одной спецификации, способной вносить ограничения на существование подобных систем (конфигурация BIOS MP-систем, протокол загрузки MP-систем, описание структур ACPI, работа APIC) я не находил запретов на их построение. Поэтому ограничения тут могут прийти только со стороны софта (firmware и OS), который может быть не готов правильно управлять ресурсами в таком случае.
Так как практическая ценность подобных конфигураций пониженная, а вот число комбинаций, на которых пришлось бы тестировать работоспособность софта, возрастает при этом существенно (из-за комбинаторного взрыва при снятии ограничения на идентичность всех узлов), я не уверен, что многие вендоры операционок готовы затрачивать ресурсы на их поддержку, сертификацию и т.п.
Ну так статья-то и называется «Процессоры, ядра и потоки», а не «Процессоры, ядра, потоки, NUMA, распределённая память, RDMA, их влияние на планировщик задач, Винни-пух и все-все-все». Надо и читателя пожалеть, в конце концов; да и автор рано или поздно поймает себя на том, что ушёл в дебри, которые он совсем не знает и про которые рассказывать не должóн.
Планируете ли вы переиздавать последнюю книгу в этом списке: «Архитектура компьютера и проектирование компьютерных систем»? В издании 2011 года печалит присутствие некоторых опечаток, а также полное отсутствие списка литературы, хотя ссылки на него в тексте книги имеются.
Выложили на всеобщее обозрение студбилет какого-то четверокурсника. Надеюсь, что с разрешения владельца. А то ведь в возрасте получения билета (~17 лет) многие на фотографии выглядят не очень уверенно.
Пруф
Эх, с какого перепоя я тут вообще оказался?
А если по теме: очень рад этой новости, как говорится, «два года ждал». Вот только под Windows мой учебный проект собирается с помощью MinGW, сборка MS VS, увы, не поддерживается (т.к. в оной студии довольно долго не поддерживались некоторые фичи C99). Как думаете, CppCat его сможет осилить в таких условиях? В принципе ведь всё-равно все вызовы MinGW развернутся в нативные WinAPI и прочие родные для ОС API.
Когда я читал статью Джоэля на английском, я именно так себе и представлял в голове: как абстракции нижнего уровня протекают на верхние уровни. Последний раз, когда я проходил тест Тьюринга, меня идентифицировали как человека, не как машину :-), поэтому оставляю за собой право переводить это именно так, хотя и не настаиваю на этом, потому что…
… в русском переводе этой книги издательства Символ-Плюс, действительно, используется термин «дырявые абстракции». У меня есть несколько претензий к переводу и оформлению книги в целом (одна только безвкусно оформленная обложка чего стоит, особенно если сравнивать с оформлением оригинала). Но опять же, это вкусовое различие, и спорить тут можно до бесконечности.
Оригинальная статья Джоэла не про безопасность, а про то, что, как ни прячь за общим интерфейсом работу с файловой системой, работа с NFS и с локальным диском не будут выглядеть одинаково — природа сетевого соединения будет неизбежно проявляться (протекать).
«Leak» — это всё-таки «течь». Хотя от перевода как «дырявый» данная метафора не сильно страдает.
Ах да, забыл сказать — я не знаток безопасности, а просто странствующий философ ☺
И ещё: в одной презентации я прочитал остроумное определение термина «хакер»: это человек, который ищет (и использует) машины Тьюринга в системах там, где их создатели не намеревались их размещать.
Скорее всего это проявление закона протекающих абстракций. И песочницы, и код, в них исполняемый, построены на одном и том же основании машинной архитектуры и соглашениях об организации памяти и других ресурсов. Хотя создатели любой песочницы стараются спрятать нижележащие слои от запускаемых приложений, эти слои никуда не уходят. Доказать формально строго корректность алгоритмов песочницы чаще всего недопустимо дорого, поэтому дыры в них всегда есть.
Diehard и сейчас есть. Есть ещё Dieharder. Есть тесты от NIST, о которых эта статья. Я в своей статье проверял свои же велосипеды, а также аппаратный RDRAND с помощью TestU01.
Кстати, в OpenRISC с кодом 0x00 связана инструкция «прыжок на себя» (бесконечный цикл), а в Itanium она вызывает исключение. Более древние архитектуры обычно не связывают с нулевым опкодом никакого особенного поведения (например, в IA-32 это вообще ADD), хотя это очень полезно при отладке. Часто исполнение по ошибке убегает в неинициализированную память, чаще всего заполненную нулями. Если не бросать исключение или не зацикливаться, то процессор как ни в чём не бывало будет исполнять нули, и к моменту обнаружения этого факта он будет уже далеко от исходного места входа в неинициализированную память.
В целом написано правильно. Если переходить от вопроса в заголовке статьи к вопросу управления энергопотреблением, который поднимается в тексте, то надо отметить ещё как минимум пару фактов.
0. На самом деле современное программное управление энергопотреблением устроено сложнее и учитывает не только центральный процессор, но и периферийные устройства.
1. Первоначально (на 8086) HLT просто «выключала» процессор, который не мог больше исполнять инструкции, до последующей перезагрузки.
2. В современных ОС на IA-32 вместо HLT для задач процесса idle используется другая инструкция — MWAIT. Она позволяет явно указывать, в насколько глубокий режим энергопотребления следует поместить процессор. Например, в драйвере intel_idle в Linux. Обсуждение относительной эффективности HLT и MWAIT/MONITOR проводится, например, в этом треде на SO.
Тогда сперва, я думаю, стоит объяснить, зачем RIP-relative адресация вообще нужна. А нужна она для эффективной поддержки т.н. position-independent code (PIC), т.е. машинного кода, работоспособность которого не зависит от его положения в памяти.
Чаще всего необходимость в PIC возникает для разделяемых библиотек. При раздельной компиляции каждой библиотеки необходимо где-то разместить данные, с которыми она работает; использующий их код будет использовать константы-смещения для их адресации. При загрузке нескольких независимых библиотек может произойти конфликт: две или более библиотек будут хотеть разместить данные по одним и тем же адресам.
Для решения этой проблемы неободимо ввести уровень косвенности: «плавающую» адресацию данных. Можно при загрузке каждой библиотеки высчитывать адреса данных заново и переписывать их прямо в коде. Можно выбрать и использовать некоторый регистр, значение которого будет определять начало блока данных для конкретной библиотеки, и изменять только его значение при переходах между ними.
Наверное, самым изящным решением является выбор указателя текущей инструкции (RIP, EIP, IP, PC, IC…) в качестве такого регистра. На этапе компиляции известно «расстояние» между инструкцией, использующей некоторую переменную, и положением самой переменной в памяти. Самое важное — эта величина не меняется, где бы в памяти мы не разместили библиотеку в будущем. Поэтому смещение относительно счётчика инструкций можно как константу зашить прямо в машинный код инструкции. При условии, что кодировка набора команд это позволяет.
Изначально Intel IA-32 не имела такой тип адресации. Смещения можно было указывать только относительно регистров общего назначения. Кроме того, не было возможности загрузить значение EIP прямо в регистр — это можно было сделать только через операции над памятью, использующие стек, и вызов подпроцедуры, помещающей EIP на стек.
(Кстати, это тот самый случай, когда попытка inline-оптимизации рушит всё веселье!)
Конечно, это всё жутко неэффективно и коряво. Поэтому в компиляторах для 32-битного режима IA-32 по умолчанию режим PIC выключен.
С приходом Intel 64 в набор инструкций был добавлен новый способ адресации (вместо неиспользуемого в 64-битном режиме 32-битного смещения при использовании байта SIB). Для него идущая после байта ModRM 32-битная константа трактуется как смещение со знаком относительно RIP.
Возможно, следующий пример поможет проиллюстрировать сказанное выше. В нём я ассемблирую программу из единственной инструкции, использующей RIP-relative адресацию операнда в памяти, и вывожу результат дизассемблирования.
user@host:~$ cat 1.s
movq %rax, 0xaabb(%rip)
user@host:~$ as 1.s
user@host:~$ objdump -d a.out
a.out: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <.text>:
0: 48 89 05 bb aa 00 00 mov %rax,0xaabb(%rip) # 0xaac2
Здесь в результирующем машинном коде 0x48 — это REX-префикс, 0x89-часть опкода, а 0x05 — байт ModRM, кодирующий, в том числе, тот факт, что используется RIP-relative адресация, и что последующие четыре байта определяют смещение (0x0000aabb) относительно адреса инструкции, следующей за текущей.
Отмечу следующие интересные моменты.
0. Практически все архитектуры поддерживают адресацию относительно текущей команды для инструкций переходов, т.е. jmp, branch, call. Не следует путать их с rip-relative адресацией — в них не происходит обращений к памяти.
1. Поддержка адресации относительно указателя текущей инструкции существует в других архитектурах, например, в ARM, VAX, 6809.
2. В английской Википедии есть исчерпывающая статья по типам адресации: en.wikipedia.org/wiki/Addressing_mode#PC-relative_2.
Сразу уточняющий вопрос — под ia64 подразумевается Intel Itanium? Если да, то в нём формата инструкции для IP-relative адресации не предусмотрено. Для написания position independent code на этой архитектуре можно просто загрузить значение ip в любой регистр общего назначения, а затем использовать его с нужным смещением.
Я планировал эту заметку как самодостаточную и раскрывающую ответ ровно на тот вопрос, который часто задаётся. Однако, если есть какие-то смежные темы, оставшиеся непонятными, то я могу попробовать описать их или тут, в обсуждении, или же в более развёрнутом виде, если потребуется.
И RISC-V. А за нелицензированную реализацию в железе некоторых ISA их хозяева довольно быстро настигают с вежливой просьбой свернуть разработку, как было с Yellow Star MIPS 3000 от тех же OpenCores, что стоят за OpenRISC.
Так как практическая ценность подобных конфигураций пониженная, а вот число комбинаций, на которых пришлось бы тестировать работоспособность софта, возрастает при этом существенно (из-за комбинаторного взрыва при снятии ограничения на идентичность всех узлов), я не уверен, что многие вендоры операционок готовы затрачивать ресурсы на их поддержку, сертификацию и т.п.
По языкам программирования в Гугле по запросу «programming languages share»
www.tiobe.com/index.php/content/paperinfo/tpci/index.html
programmers.stackexchange.com/questions/160461/programming-language-trends
По операционным системам в том же Гугле:
www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0
www.statista.com/statistics/268237/global-market-share-held-by-operating-systems-since-2009/
Эх, с какого перепоя я тут вообще оказался?
А если по теме: очень рад этой новости, как говорится, «два года ждал». Вот только под Windows мой учебный проект собирается с помощью MinGW, сборка MS VS, увы, не поддерживается (т.к. в оной студии довольно долго не поддерживались некоторые фичи C99). Как думаете, CppCat его сможет осилить в таких условиях? В принципе ведь всё-равно все вызовы MinGW развернутся в нативные WinAPI и прочие родные для ОС API.
Когда я читал статью Джоэля на английском, я именно так себе и представлял в голове: как абстракции нижнего уровня протекают на верхние уровни. Последний раз, когда я проходил тест Тьюринга, меня идентифицировали как человека, не как машину :-), поэтому оставляю за собой право переводить это именно так, хотя и не настаиваю на этом, потому что…
… в русском переводе этой книги издательства Символ-Плюс, действительно, используется термин «дырявые абстракции». У меня есть несколько претензий к переводу и оформлению книги в целом (одна только безвкусно оформленная обложка чего стоит, особенно если сравнивать с оформлением оригинала). Но опять же, это вкусовое различие, и спорить тут можно до бесконечности.
«Leak» — это всё-таки «течь». Хотя от перевода как «дырявый» данная метафора не сильно страдает.
И ещё: в одной презентации я прочитал остроумное определение термина «хакер»: это человек, который ищет (и использует) машины Тьюринга в системах там, где их создатели не намеревались их размещать.
0. На самом деле современное программное управление энергопотреблением устроено сложнее и учитывает не только центральный процессор, но и периферийные устройства.
1. Первоначально (на 8086) HLT просто «выключала» процессор, который не мог больше исполнять инструкции, до последующей перезагрузки.
2. В современных ОС на IA-32 вместо HLT для задач процесса idle используется другая инструкция — MWAIT. Она позволяет явно указывать, в насколько глубокий режим энергопотребления следует поместить процессор. Например, в драйвере intel_idle в Linux. Обсуждение относительной эффективности HLT и MWAIT/MONITOR проводится, например, в этом треде на SO.
Если будут силы и время — попробую. Про ABI так можно целый цикл заметок сделать — очень уж интересный вопрос.
Чаще всего необходимость в PIC возникает для разделяемых библиотек. При раздельной компиляции каждой библиотеки необходимо где-то разместить данные, с которыми она работает; использующий их код будет использовать константы-смещения для их адресации. При загрузке нескольких независимых библиотек может произойти конфликт: две или более библиотек будут хотеть разместить данные по одним и тем же адресам.
Для решения этой проблемы неободимо ввести уровень косвенности: «плавающую» адресацию данных. Можно при загрузке каждой библиотеки высчитывать адреса данных заново и переписывать их прямо в коде. Можно выбрать и использовать некоторый регистр, значение которого будет определять начало блока данных для конкретной библиотеки, и изменять только его значение при переходах между ними.
Наверное, самым изящным решением является выбор указателя текущей инструкции (RIP, EIP, IP, PC, IC…) в качестве такого регистра. На этапе компиляции известно «расстояние» между инструкцией, использующей некоторую переменную, и положением самой переменной в памяти. Самое важное — эта величина не меняется, где бы в памяти мы не разместили библиотеку в будущем. Поэтому смещение относительно счётчика инструкций можно как константу зашить прямо в машинный код инструкции. При условии, что кодировка набора команд это позволяет.
Изначально Intel IA-32 не имела такой тип адресации. Смещения можно было указывать только относительно регистров общего назначения. Кроме того, не было возможности загрузить значение EIP прямо в регистр — это можно было сделать только через операции над памятью, использующие стек, и вызов подпроцедуры, помещающей EIP на стек.
(Кстати, это тот самый случай, когда попытка inline-оптимизации рушит всё веселье!)
Конечно, это всё жутко неэффективно и коряво. Поэтому в компиляторах для 32-битного режима IA-32 по умолчанию режим PIC выключен.
С приходом Intel 64 в набор инструкций был добавлен новый способ адресации (вместо неиспользуемого в 64-битном режиме 32-битного смещения при использовании байта SIB). Для него идущая после байта ModRM 32-битная константа трактуется как смещение со знаком относительно RIP.
Возможно, следующий пример поможет проиллюстрировать сказанное выше. В нём я ассемблирую программу из единственной инструкции, использующей RIP-relative адресацию операнда в памяти, и вывожу результат дизассемблирования.
Здесь в результирующем машинном коде 0x48 — это REX-префикс, 0x89-часть опкода, а 0x05 — байт ModRM, кодирующий, в том числе, тот факт, что используется RIP-relative адресация, и что последующие четыре байта определяют смещение (0x0000aabb) относительно адреса инструкции, следующей за текущей.
Отмечу следующие интересные моменты.
0. Практически все архитектуры поддерживают адресацию относительно текущей команды для инструкций переходов, т.е. jmp, branch, call. Не следует путать их с rip-relative адресацией — в них не происходит обращений к памяти.
1. Поддержка адресации относительно указателя текущей инструкции существует в других архитектурах, например, в ARM, VAX, 6809.
2. В английской Википедии есть исчерпывающая статья по типам адресации: en.wikipedia.org/wiki/Addressing_mode#PC-relative_2.
Или всё-таки имелась в виду архитектура Intel 64?