Я на этот вопрос уже отвечал некоторое время назад.
автокопипаст
Любая торговая марка после её регистрации принадлежит компании только при условии, что эта компания отстаивает своё право на эксклюзивное использование вот именно этой комбинации слов. Если же слово/фраза становится нарицательным, или им начинают обозначать нечто большее, чем было изначально задумано, и не ассоциируют с правообладателем, то в суде исключительное право на использование как торговой марки после этого уже не отстоять.
Такое случалось в истории. Такие слова, как «капрон», «героин» и т.д. Я был очень удивлён, узнав совсем недавно, что «термос» — это тоже торговая марка! Обратный пример: компания Google отказала Оксфордскому словарю во включении глагола «to google» в словарь по тем же самым причинам.
По этой причине сотрудников любой компании обязуют в публичных коммуникациях обозначать торговые марки вот этими дурацкими символами. Потому что если уж даже члены компании не защищают торговую марку, и есть документальные подтверждения в виде постов на форумах, то в суде при случае отстоять ничего не получится.
Кстати, забавно смотрелся текст диплома одного студента нашей кафедры. Вроде бы документ для внутреннего использования, а всё равно пролезли всякие ® (tm). Я даже попросил вроде поубавить немного их число.
Любые обещания по точности таймеров ломаются на SMM.
Для измерения периодов времени, действительно, SMM создаёт неконтролируемую задержку. Но SMM само по себе не мешает измерять точно время — исполнение кода внутри этого режима не останавливает таймеры.
Нужно понимать, что на длительность исполнения программы в современных IA-32 может непредсказуемым образом повлиять много других факторов, иногда меньшего, а иногда и большего порядка. Так, промахи кэша не позволят гарантировано измерять периоды короче сотни тактов, ошибки предсказателя переходов — десятки тактов, а варьирующаяся частота процессора так и вообще может изменить время работы блока кода в разы. Другими словами, если нужен жёсткий реалтайм, то следует выбирать подходящую архитектуру или хотя бы конфигурацию аппаратуры (т.е. проц без SMM, с выключенными кэшами, in-order выполнением и прочим).
SMM по сути — это просто ещё один режим супервизора. Кстати, интересные эффекты возникают, когда надо подружить SMM с VMX root режимом — вроде бы два главных супервизора, а вот кто из них главнее? Даже специальный dual-monitor mode для виртуализации VT-x ввели, в котором эти друзья более-менее договариваются о зонах влияния.
Хочу комментария Intel зачем такую штуку делали (SMM).
В 80386 был недокументированный режим ICE для отладки, в который можно было попасть в том числе дёргая недокументированный пин. По тому, как он работал, он очень напоминал System Management Mode, каким мы видим его сейчас. Очевидно, кому-то пришла идея переиспользовать отладочный ICE-режим в форме SMM для других нужд.
Изначально SMM использовался в мобильных процессорах 386 для того, чтобы управлять энергопотреблением процессора ОС-агностичным образом. В то время представлялось, что легче сделать так, чем пытаться обучить однозадачную DOS во всех её вариантах управлению питанием.
В принципе это работало неплохо, но кому-то из вендоров BIOS пришла идея переиспользовать SMM для других нужд. В обработчик SMI стали добавлять всё подряд — от эмуляции PS/2 до живительных руткитов.
так удивительно: точное время нужно для всех программ, но для этого до сих пор нет ничего простого.
В игру вступает множество факторов: поддержка legacy-кода, который знать не знает про новый девайс, стоимость и размеры (встроить батарейку в процессор ещё не додумались, а убертаймер должен быть поближе к нему), передача сигнала во много мест сразу не так проста — он же не мгновенно по проводам бежит.
С другой стороны моя гипотеза сломалась бы на виртуализации.
Об этом я постараюсь написать в ближайшее время. Если кратко, то время при виртуализации — это веселье в квадрате.
Эта книга, похоже, по тематике находится посередине между Хоровиц-Хиллом и Хеннесси-Паттерсоном. Если это действительно так, то это отличные новости! Наконец-то!
Спасибо всем авторам и переводчикам за труд!
Спасибо за статью! Было бы интересно узнать Ваше отношение к Bios Guard поподробнее. Я по работе вроде бы и связан с низкоуровневыми фазами загрузки на IA, но вот конкретно Bios Guard как-то прошло мимо меня. Тем интереснее узнать мнение сторонних разработчиков об этой и подобных тенденциях в UEFI-строении.
А вот подскажите, пожалуйста, какие есть подходы к следующей проблеме, и может ли VTune тут помочь.
Есть приложение, которое поставляется со специальным модулем ядра. Оно работает в тесной связке с ним, в принципе может проводить в нём 50-70% процентов времени, это нормально. И есть задача по профилировке приложения в связке с модулем ядра, потому что тормоза в различных сценариях возникают то в юзерспейсе, то в ядре. Есть возможность всё собрать с отладочными символами. Да, всё делается в Linux, но случай с Windows не менее интересен.
Однако «заглянуть» в ядро и корректно собрать callstack'и как-то не получается. По какой-то причине предыдущий VTune при отображении callstack останавливается на границе ядра. Вроде и права все есть, и sep драйвер загружен.
perf_events, которые с Linux идут, честно признаются, что для динамически загруженных или релоцированных модулей ядра perf вряд ли будет полезен; однако в своём репорте он каким-то волшебным образом показывает имена функций в модуле ядра, попавших в топ. Это уже ограниченно полезно. Стек вызовов при этом отсутствует, source-вид не работает, даже ассемблер не показывается.
Есть ли решение для подобных сценариев профилировки (приложение+модуль ядра)?
Это да. Я сам был удивлён, когда мне товарищ, работающий в одной российской компании по проектированию и производству микропроцессорных систем, поведал, что ассемблеры у них в принципе могут и распределением ресурсов заниматься. Я такого сам не видел, но вполне могу представить. Руками для VLIW пытаться это сделать быстро и правильно почти невозможно.
Безусловно, кодогенерация под целевую архитектуру — не менее важный и захватывающий вопрос в построении JIT.
В Вашем подходе я вижу пару моментов, которые, возможно, ограничивают скорость генерированного кода или гибкость подхода в целом.
1. Использование x87 инструкций для работы с Float-числами. x87 — довольно старое расширение, не самое удобное для программирования и возможно не самое быстрое. Можно попробовать заменить целевой набор инструкций на какой-нибудь вариант SSE. Причём не с целью использовать их «векторность», а для облегчения программируемости; да и ядру их будет легче планировать.
2. Максимально использовать регистры для хранения промежуточных результатов. Обращения к памяти дорогого стоит, и это ограничивает скорость. Это потребует хотя бы тривиального распределения регистров при работе; возможно, просто организация программного стека с верхушкой на регистрах, а хвостом в памяти с автоматической подкачкой/выкачкой нужных значений.
А какие можете посоветовать альтернативные «лёгкие» способы это сделать? Из моего опыта так создание и поддержка компилятора любого типа (с ЯВО или двоичного кода) никогда не было лёгкой задачей. Появление LLVM дало надежду на создание хоть какого-то общего фундамента.
По теме компиляции выражений с языка высокого уровня в машинный код есть очень интересный и сравнительно простой учебник от проекта LLVM, использующий, конечно же, фреймворк LLVM: Kaleidoscope: Implementing a Language with LLVM. Написано без всей этой заумности Dragon Book, для первого знакомства очень удобно.
Поскольку LLVM решает проблемы кодогенерации для целевой архитектуры, в этом учебнике больше уделяется внимания написанию рекурсивного парсера, перевода кода в промежуточное представление (AST, LLVM IR) и простых преобразований над ним.
Ещё бывает такой вариант, как «шкалирование». Хотя это уже скорее из области матстатистики. «Масштабирование» — уже достаточно заимствованное слово (звучит на немецкий лад).
Читайте, пожалуйста, исходник внимательно. Там наверняка widow, а не window. Да хотя бы из Википедии:
В справочной литературе различают «верхнюю висячую строку» (англ. widow — вдова) и «нижнюю висячую строку» (англ. orphan — сирота). На русском типографском жаргоне и то, и другое называют...
Спасибо за статью. Очень интересно, что там сделали для ускорения PIC в 32-битном коде. Буквально недавно тут поднималось обсуждение этой темы. Жду продолжения с нетерпением!
Особенно весело становится, когда инструкции имеют три операнда, а сама операция некоммутативна, и приходится мучительно пытаться удержать в голове, каков их порядок: src1, src2, dst или dst, src1, src2; а может dst, src2, src1?
Ах, да. В мнемониках команд в нотации Intel есть один ньюанс — для некоторых векторных команд порядок операндов соответствует AT&T, а для некоторых нет.
По-моему, эта штука — первая за долгое время вещь у Lenovo в серии Thinkpad, которая выглядит как шаг вперёд, а не как шаг в пропасть, как это происходит с ноутбуками серии. После того, как на X1 убрали ряд клавиш F1-F12, я уже боюсь представить, что будет дальше (убрать Ctrl и Alt? Объединить Backspace и Delete, а Home — c End? Ой, подождите, это же уже сделано!)
Безусловно, гетерогенные системы имеют право быть. Более того, у Intel есть как минимум два примера таких сценариев для IA-32. Интересно, что они находятся по разные стороны от «классических» десктопных/серверных систем в компьютерном континуме.
1. HPC-системы с процессорами Xeon в сокетах ЦПУ и Xeon Phi — в слотах PCIe. Низкоуровновое взаимодействие между ними происходит по протоколам стандарта PCIe (Memory mapped IO для запросов от ЦПУ к сопроцессору и DMA/прерывания для ответов с сопроцессора к ЦПУ). А так — на каждом крутится своя ОС, и информация о топологии должны передаваться более верхнеуровневыми протоколами между этими ОС.
2. Встраиваемая система Intel Edison c процессорами Intel Atom и Intel Quark. На первом крутится Linux, на втором — RTOS. Я, к стыду своему, пока ещё не знаю, как устроено низкоуровневое взаимодействие между ними, но опять же наличие двух ОС означает, что оно должно проходить через протокол высокого уровня, понятный обеим.
Мой ответ выше был, скорее, о системах с несколькими различными процессорами общего назначения. В обоих случаях описанных выше гетерогенных систем «весовая категория» входящих в них ядер разная, и между ними находятся довольно высокие барьеры к взаимодействию на аппаратном уровне. Однако, они оборачиваются удобством для задач прикладного программирования, от которого эта гетерогенность или прячется, или же чётко артикулируется и контролируется самой ОС и выбранной парадигмой программирования.
Кстати, забавно смотрелся текст диплома одного студента нашей кафедры. Вроде бы документ для внутреннего использования, а всё равно пролезли всякие ® (tm). Я даже попросил вроде поубавить немного их число.
Для измерения периодов времени, действительно, SMM создаёт неконтролируемую задержку. Но SMM само по себе не мешает измерять точно время — исполнение кода внутри этого режима не останавливает таймеры.
Нужно понимать, что на длительность исполнения программы в современных IA-32 может непредсказуемым образом повлиять много других факторов, иногда меньшего, а иногда и большего порядка. Так, промахи кэша не позволят гарантировано измерять периоды короче сотни тактов, ошибки предсказателя переходов — десятки тактов, а варьирующаяся частота процессора так и вообще может изменить время работы блока кода в разы. Другими словами, если нужен жёсткий реалтайм, то следует выбирать подходящую архитектуру или хотя бы конфигурацию аппаратуры (т.е. проц без SMM, с выключенными кэшами, in-order выполнением и прочим).
SMM по сути — это просто ещё один режим супервизора. Кстати, интересные эффекты возникают, когда надо подружить SMM с VMX root режимом — вроде бы два главных супервизора, а вот кто из них главнее? Даже специальный dual-monitor mode для виртуализации VT-x ввели, в котором эти друзья более-менее договариваются о зонах влияния.
Ниже будет мой личный комментарий того, как я понимаю историю сего явления.
Мой краткий пересказ описания истории SMM отсюда: blogs.msdn.com/b/carmencr/archive/2005/08/31/458609.aspx и www.rcollins.org/ddj/Jan97/Jan97.html,
В 80386 был недокументированный режим ICE для отладки, в который можно было попасть в том числе дёргая недокументированный пин. По тому, как он работал, он очень напоминал System Management Mode, каким мы видим его сейчас. Очевидно, кому-то пришла идея переиспользовать отладочный ICE-режим в форме SMM для других нужд.
Изначально SMM использовался в мобильных процессорах 386 для того, чтобы управлять энергопотреблением процессора ОС-агностичным образом. В то время представлялось, что легче сделать так, чем пытаться обучить однозадачную DOS во всех её вариантах управлению питанием.
В принципе это работало неплохо, но кому-то из вендоров BIOS пришла идея переиспользовать SMM для других нужд. В обработчик SMI стали добавлять всё подряд — от эмуляции PS/2 до живительных руткитов.
P.S. Я вспомнил, что об этом я уже писал!
В игру вступает множество факторов: поддержка legacy-кода, который знать не знает про новый девайс, стоимость и размеры (встроить батарейку в процессор ещё не додумались, а убертаймер должен быть поближе к нему), передача сигнала во много мест сразу не так проста — он же не мгновенно по проводам бежит.
Об этом я постараюсь написать в ближайшее время. Если кратко, то время при виртуализации — это веселье в квадрате.
Спасибо всем авторам и переводчикам за труд!
Очень понравился вывод!
Есть приложение, которое поставляется со специальным модулем ядра. Оно работает в тесной связке с ним, в принципе может проводить в нём 50-70% процентов времени, это нормально. И есть задача по профилировке приложения в связке с модулем ядра, потому что тормоза в различных сценариях возникают то в юзерспейсе, то в ядре. Есть возможность всё собрать с отладочными символами. Да, всё делается в Linux, но случай с Windows не менее интересен.
Однако «заглянуть» в ядро и корректно собрать callstack'и как-то не получается. По какой-то причине предыдущий VTune при отображении callstack останавливается на границе ядра. Вроде и права все есть, и sep драйвер загружен.
perf_events, которые с Linux идут, честно признаются, что для динамически загруженных или релоцированных модулей ядра
perfвряд ли будет полезен; однако в своём репорте он каким-то волшебным образом показывает имена функций в модуле ядра, попавших в топ. Это уже ограниченно полезно. Стек вызовов при этом отсутствует, source-вид не работает, даже ассемблер не показывается.Есть ли решение для подобных сценариев профилировки (приложение+модуль ядра)?
Да.
Разных. В основном компоненты, отвечающие за центральные и вспомогательные процессоры.
В Вашем подходе я вижу пару моментов, которые, возможно, ограничивают скорость генерированного кода или гибкость подхода в целом.
1. Использование x87 инструкций для работы с Float-числами. x87 — довольно старое расширение, не самое удобное для программирования и возможно не самое быстрое. Можно попробовать заменить целевой набор инструкций на какой-нибудь вариант SSE. Причём не с целью использовать их «векторность», а для облегчения программируемости; да и ядру их будет легче планировать.
2. Максимально использовать регистры для хранения промежуточных результатов. Обращения к памяти дорогого стоит, и это ограничивает скорость. Это потребует хотя бы тривиального распределения регистров при работе; возможно, просто организация программного стека с верхушкой на регистрах, а хвостом в памяти с автоматической подкачкой/выкачкой нужных значений.
Поскольку LLVM решает проблемы кодогенерации для целевой архитектуры, в этом учебнике больше уделяется внимания написанию рекурсивного парсера, перевода кода в промежуточное представление (AST, LLVM IR) и простых преобразований над ним.
Читайте, пожалуйста, исходник внимательно. Там наверняка widow, а не window. Да хотя бы из Википедии:
Опять же, есть устоявшееся «нижний колонтитул».
Ах, да. В мнемониках команд в нотации Intel есть один ньюанс — для некоторых векторных команд порядок операндов соответствует AT&T, а для некоторых нет.
1. HPC-системы с процессорами Xeon в сокетах ЦПУ и Xeon Phi — в слотах PCIe. Низкоуровновое взаимодействие между ними происходит по протоколам стандарта PCIe (Memory mapped IO для запросов от ЦПУ к сопроцессору и DMA/прерывания для ответов с сопроцессора к ЦПУ). А так — на каждом крутится своя ОС, и информация о топологии должны передаваться более верхнеуровневыми протоколами между этими ОС.
2. Встраиваемая система Intel Edison c процессорами Intel Atom и Intel Quark. На первом крутится Linux, на втором — RTOS. Я, к стыду своему, пока ещё не знаю, как устроено низкоуровневое взаимодействие между ними, но опять же наличие двух ОС означает, что оно должно проходить через протокол высокого уровня, понятный обеим.
Мой ответ выше был, скорее, о системах с несколькими различными процессорами общего назначения. В обоих случаях описанных выше гетерогенных систем «весовая категория» входящих в них ядер разная, и между ними находятся довольно высокие барьеры к взаимодействию на аппаратном уровне. Однако, они оборачиваются удобством для задач прикладного программирования, от которого эта гетерогенность или прячется, или же чётко артикулируется и контролируется самой ОС и выбранной парадигмой программирования.