Здравствуйте, IID, Вы писали:
IID>И когда у тебя, потенциально, завиртуализировано ВСЁ. Как НАДЕЖНО и в общем случае понять, на реальном железе ты исполняешься, или под виртуалкой.
Это больше теория, чем практика. Чтоб виртуализовать "ВСЁ", в составе этого "всего" должны быть все без исключения аппаратные средства, встречающиеся в типовой системе, а их уже в конце 90-х было немало, со всеми их особенностями и неявными багами. Если тщательно сэмулировать систему определенной конфигурации, то "неузнаваемой" она пробудет недолго, а потом ее начнут детектить тупо по аппаратной сигнатуре. Эмулировать же достаточное количество различных конфигураций — адская работа, за которую взялись бы только с целью какой-нибудь грандиозной масштабной аферы. Ну, или какие-нибудь безумцы, одержимые сверхцелью.
Здравствуйте, IID, Вы писали:
IID>>>Вспомни, как детектили BluePill.
ЕМ>>Я не вдавался, в чем там были сложности?
IID>Вложенная виртуализация. До Bluepill наивно считалось, что если ты не смог перейти в режим гипервизора — значит он уже запущен. И детект тривиальный.
В стиле Википедии тут после "наивно считалось" должна стоять верхняя плашка "[кем?]" Отдельными представителями мира x86? В VM/370 такая вложенная виртуализация поддерживалась ещё в конце 1970-х. К тому же уровень вложенности в VM/370 был уже неограниченным (реально, начиная с 3-го, по доступным мне отзывам, начинались заметные тормоза, с 4-го уже они не давали нормально работать). Это при том, что в SystemZ до сих пор нет nested paging! (или я не так читаю?)
Рутковская, безусловно, гений, но для осознания принципиальной возможности было достаточно знаний за пределами мирка PC/Wintel. Подробнейшая документация к VM/370 была тогда точно доступна. Код — возможно, я не знаю, когда его открыли, но уже по документации можно было понять не только, что это возможно, но и методы.
Аппаратная вложенность в современном x86 в виде VMCS/VMCB shadowing и аналог в AArch64 дают только два уровня, дальше тоже надо софтово.
Это не к основной теме, просто некоторые детали в вашем комментарии таки хотелось уточнить.
ЕМ>>ее реализация должна позволять полностью воспроизвести исходную конфигурацию (то есть — возможность неограниченной вложенности), а такого, насколько я знаю, ни один процессор не поддерживает.
IID>И опять напомню про BluePill — там сделали вложенную виртуализацию "руками". Задолго, до появления железной поддержки вложенности.
Всё равно есть проблема потери скорости (неравномерной, зависимой от вида действий) и неточного воспроизведения поведения железа. В задачах Евгения (звуковые драйвера) это может быть критично.
Здравствуйте, netch80, Вы писали:
N>Уложить в мелкие ресурсы крупную задачу это наверняка много хитростей
Ну, мы с коллегами никогда не доходили до того, чтоб заниматься самомодификацией, передачей управления "внутрь" команд и подобными трюками, которые вынуждены использовать авторы конкурсных программ с жестким ограничением на ресурсы. Как-то всегда хватало традиционного. Не хватает адресного пространства — используются переключаемые страницы/банки (если они есть на платформе), не хватает оперативной памяти — перекрытия/оверлеи, не хватает скорости вычислений — приближения, предвычисления, табличные функции и подобное.
Поскольку "узкие" по ресурсам задачи тогда решались преимущественно на ассемблерах, всегда было достаточно четкое представление о реально потребных для конкретной задачи объемах ресурсов. Современные представления об этих объемах, как правило, завышены на несколько порядков. Многое из того, что типичный современный программист едва сумеет втиснуть в возможности среднего железа выпуска 2008-2012, тогдашний программист реализовал бы на каком-нибудь 486, а то и 386, разве что не так красиво и развесисто. Исключая, понятное дело, объективно тяжелые вычисления, и столь же объективно тяжелые данные (например, видеопотоки), вытекающие непосредственно из задачи, а не из наиболее типовых и удобных методов ее решения.
Здравствуйте, netch80, Вы писали:
N>Всё равно есть проблема потери скорости (неравномерной, зависимой от вида действий) и неточного воспроизведения поведения железа.
Можно накосячить и куда проще. Я до сих пор не перехожу с VMware Workstation 12, поскольку в старших версиях поломали виртуализацию асинхронного обмена с дисковыми устройствами. Наверное, разработчики уже тогда накупили себе SSD и решили, что асинхронный обмен себя изжил, пора переходить к синхронному, дабы выиграть сотни микросекунд любой ценой. В итоге, даже если и хост, и VM работают только с SSD, синхронная операция чтения/записи все равно блокирует VM на те самые сотни микросекунд, и лаги обработки прерываний/DPC и прочих асинхронных событий становятся несуразно большими. Звуковые потоки с небольшими буферами это ломает в первую очередь, но эти ребята проверяли, скорее всего, на вычислениях и видео, а там оно совершенно незаметно.
Пытался по этому поводу бодаться с VMware — они сперва стали жевать сопли, а потом написали, что единственный Support Case, входивший в мою подписку, они исчерпали, и предложили купить новый. Я их послал и забил, благо версия 12 до сих пор вполне годится для отладки.
Здравствуйте, jamesq, Вы писали:
J>Нынешние владельцы EPYC Genoa с 64 ядрами и терабайтом ОЗУ откровенно зажратые типы по сравнению с подобным. У которых одних транзисторов на чипе в 15 миллионов раз больше.
Эх, помню времена, когда наличие barrel shifter было конкурентным преимуществом и оговаривалось отдельно Часто он появлялся из-за надобности плавучки, но не обязательно.
Здравствуйте, andyp, Вы писали:
A>Эх, помню времена, когда наличие barrel shifter было конкурентным преимуществом и оговаривалось отдельно Часто он появлялся из-за надобности плавучки, но не обязательно.
Те времена я не застал вообще. Про barrel shifter узнал только сейчас от тебя.
Я только сейчас, в 2025 в подробностях выясняю, насколько ограничены были процессоры 70-х и 80-х. Ну может кое-что знал про 8086. Само собой, уже четверть века знаю про 16-битный реальный режим, но не суть.
Хочу сказать, что сверху всех ограниченных возможностей 8-битных процессоров идёт то, что:
1. Они работали на частоте в единицы мегагерц
2. А впридачу, команды не выполнялись за один такт. Дай бог за 4 — самые быстрые. А то и по 10-20 тактов.
В общем, все эти процессоры откровенно убоги.
Я вчера писал процедурку взятия противоположного от 32-х битного числа со знаком.
То, что в нормальном процессоре уже в 1990-х делалось одной инструкцией, выполняющейся за 1 такт, здесь мне пришлось прогонять всё это число побайтово через аккумулятор, инвертируя разряды и добавляя carry bit.
Вся история заняла аж 16 инструкций, и выполняется наверное 64 такта. И это на 2 МГц процессоре, ага.
Здравствуйте, jamesq, Вы писали:
J>Я только сейчас, в 2025 в подробностях выясняю, насколько ограничены были процессоры 70-х и 80-х. Ну может кое-что знал про 8086. Само собой, уже четверть века знаю про 16-битный реальный режим, но не суть. J>Хочу сказать, что сверху всех ограниченных возможностей 8-битных процессоров идёт то, что: J>1. Они работали на частоте в единицы мегагерц J>2. А впридачу, команды не выполнялись за один такт. Дай бог за 4 — самые быстрые. А то и по 10-20 тактов.
Я всё-таки попридерусь к деталям, они существенны для понимания:
1. В самом современном процессоре команды не выполняются за один такт! Вместо этого выполняется, например, 30 команд за 10 тактов, если оптимально налажен код на это. Или 10 команд за 40 тактов, если в коде сплошные кросс-зависимости и нет заранее подкачанных данных. Но одна команда выполняется всё равно за несколько тактов. Минимум — два, среднее — от 5 до 10. Потому что собственно длина такта обычно рассчитывается так, чтобы соответствовать где-то двум операциям сложения значения длиной в слово. (Схемотехники скажут, что это слишком грубая оценка, но для старта сойдёт.)
А вот out-of-order — то, что позволяет достичь суммарной скорости повыше за счёт параллельной обработки. Но и ресурсов на это надо дохрена. Считаем, от миллионов вентилей.
(Бывают замедленные контроллеры, в которых даже деление выполняется за 1 такт. Но это намеренное дизайнерское решение.)
2. Почему в 8080 обычный NOP тратил 4 такта — не знаю, но в 6502 он тратил 2 такта. Фактически у него скорость была одинакова (2 мкс в обоих, за счёт того, что первые 8080 шли под 2MHz, 6502 — под 1MHz). Если бы 8080 был сделан чуть умнее, вероятно, и он бы быстрее работал. Но он был чуть раньше.
Всё равно расчёт шёл на финальную скорость выполнения программы, а она постепенно повышалась и процессоры одного ценового класса были примерно одинаковы в этом.
(Цена — отдельный вопрос. Когда 6800 и 8080 продавались за 175$, 6502 пошёл за 25$... и это была чудовищная подстава. Неудивительно, что на его создателей взъелись.)
J>В общем, все эти процессоры откровенно убоги. J>Я вчера писал процедурку взятия противоположного от 32-х битного числа со знаком. J>То, что в нормальном процессоре уже в 1990-х делалось одной инструкцией, выполняющейся за 1 такт, здесь мне пришлось прогонять всё это число побайтово через аккумулятор, инвертируя разряды и добавляя carry bit.
Ну а если ты в современном x86 выполнишь задачу отрицания (negating) 256-битного числа, тебе придётся прогонять его порциями по 64 бита через регистры, "инвертируя разряды и добавляя carry bit". И о чём это говорит, кроме того, какой тебе доступен размер операций и какой нужен? А зачем на таком процессоре тебе отрицание 32-битного числа? Это там нетипичная операция.
Я тебе больше скажу — даже 8-битное отрицание таким образом на Z80 выполнялось в два приёма, потому что его АЛУ было 4-битным. То есть реально на нём это было 8 шагов.
А какая-нибудь S/360 Model 30, за десять лет до того, тоже выполняла операции побайтно, потому что у неё 8-битный АЛУ, но команда была одна, потому что все эти детали были спрятаны в микрокоде (говоря современным термином). А Model 50 имела 32-битный АЛУ, но и стоила она от полутора миллионов тогдашних долларов.
J>Вся история заняла аж 16 инструкций, и выполняется наверное 64 такта. И это на 2 МГц процессоре, ага.
Выполняется дольше, если ты про 8080. 4 такта это NOP. "ADC M" — 7 тактов. "INX H" — 5 тактов. "XRI" — 7 тактов. Тайминги открыты, подсчитай сам.
Да. Закон Мура и аналогичные про удвоение ресурсов, скорости и пр. за полтора-два года — придумали не зря. С, условно, 1971 (год Intel 4004) до 2005 (когда рост тактовой точно остановился и начали думать и об оптимизации внутренней логики) это рост от 2↑17 = 131072 до 2↑25.5 = 47млн только формально по Муру. Реальные цифры где-то посредине. Но и сейчас есть что выжимать из технологии.
Здравствуйте, jamesq, Вы писали:
J>В общем, все эти процессоры откровенно убоги.
Если учесть, что проектировались они практически вручную и сравнивать с тем, что было до них — это просто чудо. HDL появились в середине 80х. А так — нарисуй схемку, разведи, размести, создай масочки, напыли, вытрави... Ошибся — выкинь и начни сначала. Ну и если сравнить с тем, что было, а не с тем, что стало через 30 лет, они открывали охренительные новые горизонты во многих вещах.
J>Я вчера писал процедурку взятия противоположного от 32-х битного числа со знаком. J>То, что в нормальном процессоре уже в 1990-х делалось одной инструкцией, выполняющейся за 1 такт, здесь мне пришлось прогонять всё это число побайтово через аккумулятор, инвертируя разряды и добавляя carry bit. J>Вся история заняла аж 16 инструкций, и выполняется наверное 64 такта. И это на 2 МГц процессоре, ага.
Ну да. Простейшие вещи стоили много труда, а неправильно организованные вычисления приводили к невозможности вычислить то что надо. Поэтому код и наработки были настолько ценны. Сейчас — это мусор.
Здравствуйте, jamesq, Вы писали:
J>команды не выполнялись за один такт.
Выполнялись даже во многих машинах 60-70-х. Но это касалось, понятное дело, именно выполнения самой операции, после загрузки всех операндов в регистры, и до записи результатов в память (если было запрошено).
А известная БЭСМ-6 вообще не имела команды сдвига. Вместо этого у нее были две команды — "битовая разборка" и "битовая сборка". Первая раскидывала идущие подряд разряды сумматора по позициям, указанным единичными разрядами операнда, а вторая, наоборот, собирала с этих позиций в "плотную" группу. Всё это, как и большинство команд, выполнялось за один такт, а машина была транзисторная. У нее было всего 38 команд, включая несколько служебных (недоступных прикладному программисту), но писать под нее на ассемблере было весьма удобно.
J>В общем, все эти процессоры откровенно убоги.
Понятное дело — это ж были, по большому счету, обрубки нормальных "больших" процессоров, изначально предназначенные сугубо для частных, ограниченных задач. БОльшая часть усовершенствований в сфере микропроцессоров — это отнюдь не новшества, а воспроизведение уже существовавших когда-то решений, как в исходном виде, так и с изменениями под новые обстоятельства.
J>Я вчера писал процедурку взятия противоположного от 32-х битного числа со знаком. J>То, что в нормальном процессоре уже в 1990-х делалось одной инструкцией, выполняющейся за 1 такт
В нормальных процессорах это делалось за один такт еще в 50-х.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А известная БЭСМ-6 вообще не имела команды сдвига. Вместо этого у нее были две команды — "битовая разборка" и "битовая сборка". Первая раскидывала идущие подряд разряды сумматора по позициям, указанным единичными разрядами операнда, а вторая, наоборот, собирала с этих позиций в "плотную" группу. Всё это, как и большинство команд, выполнялось за один такт, а машина была транзисторная.
Вот тут очень интересно — точно за один такт? Потому что сборка и разборка (то, что в x86 сейчас называется pext и pdep соответственно) это крайне сложные в реализации, если без цикла, команды, для них специально для скорости работы придумывали специальные сети вентилей, которые окупаются, IMHO, ну как минимум от технологии 1990-го, не раньше.
Если есть источник на это утверждение, прошу его указать.
Кстати, тут приводится некоторая shift immediate, которая однозначно сдвиг. Так что утверждение про "вообще не имела" как-то сомнительно.
EM> У нее было всего 38 команд, включая несколько служебных (недоступных прикладному программисту), но писать под нее на ассемблере было весьма удобно.
Я почитал описание... как-то совершенно неровно в размерах, за этим надо постоянно следить. В код эмулятора не лез.
J>>Я вчера писал процедурку взятия противоположного от 32-х битного числа со знаком. J>>То, что в нормальном процессоре уже в 1990-х делалось одной инструкцией, выполняющейся за 1 такт
ЕМ>В нормальных процессорах это делалось за один такт еще в 50-х.
Ну если "нормальный" это ценой от миллиона тогдашних $, то согласен
Здравствуйте, netch80, Вы писали:
N>Рутковская, безусловно, гений
Она (а может быть и он) больше гений пиара. А ещё ппц высоченная(-ный).
Реальную работу, кстати, сделал Александр Терешкин (ник 90210). но его постепенно подчистили из истории, заменив поляком.
IID>>И опять напомню про BluePill — там сделали вложенную виртуализацию "руками". Задолго, до появления железной поддержки вложенности.
N>Всё равно есть проблема потери скорости (неравномерной, зависимой от вида действий) и неточного воспроизведения поведения железа.
Конечно есть потеря скорости. Но как её измерить, без внешнего наблюдателя, и когда нет доверия к локальным источникам данных.
N>В задачах Евгения (звуковые драйвера) это может быть критично.
Каких ещё драйверов ?
я думал мы жвачку для мозгов жуём, с подачи ТС, размышляем о вариантах реализации отладчиков.
Здравствуйте, netch80, Вы писали:
N>точно за один такт?
Не, наврал — в документации на АЛУ указано 53 такта. Я и сам сомневался, что они на голых транзисторах нагородили сложных матриц для произвольной коммутации разрядов.
N>Кстати, тут приводится некоторая shift immediate, которая однозначно сдвиг.
Это сдвиг не данных, а адреса памяти (смещение относительно адреса). Ну вот назвали почему-то так. Там вместо сложных методов адресации были специальные команды прибавления адреса из регистра или ячейки памяти ко внутреннему регистру-модификатору адреса (РМА). Можно было подряд выполнить несколько таких команд, последовательно сдвигая адрес к нужной базе, а адрес в поле команды или индексном регистре затем использовался, как смещение относительно этой базы.
N>Так что утверждение про "вообще не имела" как-то сомнительно.
Битового сдвига действительно не было. Двигали или сборкой/разборкой, или умножением/делением на степень двойки.
N>как-то совершенно неровно в размерах, за этим надо постоянно следить.
А привычка очень быстро вырабатывалась. Мы программы часто даже не писали, сразу набирали в редактор из головы. В основном же работа с данными идет вокруг объектов в памяти, а в БЭСМ-6 как раз был специальный разряд в поле команды, обозначающий смещение вверх или вниз от адреса в индексном регистре. А для сложных способов адресации были как раз те самые адресные сдвиги.
N>Ну если "нормальный" это ценой от миллиона тогдашних $, то согласен
Так те процессоры вполне отрабатывали свои миллионы, разумно распределяя свои ресурсы, а не разбазаривая, как сейчас.
Здравствуйте, IID, Вы писали:
IID>Конечно есть потеря скорости. Но как её измерить, без внешнего наблюдателя, и когда нет доверия к локальным источникам данных.
Например, посчитать статистику скорости срабатывания различных операций разных устройств — MMU, APIC, North/South Bridges, PCI, USB и т.п. Виртуализовать все это так, чтоб до наносекунд соблюсти все времянки реального железа, адски сложно (и столь же дорого).
Здравствуйте, yoyozhik, Вы писали:
Y>Но просто для само развития:
Y>Есть современные аналоги? x64dbg
Y>И да, в мире linux есть современные аналоги? gdb
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Например, посчитать статистику скорости срабатывания различных операций разных устройств — MMU, APIC, North/South Bridges, PCI, USB и т.п. Виртуализовать все это так, чтоб до наносекунд соблюсти все времянки реального железа, адски
сложно (и столь же дорого).
а наносекунды ты чем будешь засекать ? таймером, которому доверия нет
кстати, на ARM давно намечена тенденция выносить работу с железом в Secure World. Чтобы после компрометации ядра HLOS ты не мог устроить армагеддон, напримев занизив напряжение питания или неприлично разогнав камень. Также Secure World может перехватывать события от устройств, и даже быть третьим этапом трансляции страниц (второй — гипервизор). И что-то там замерять дело неблагодарное. Мало того что оно сильно от устройств будет отличаться, так ещё и от профилей питания, и, конечно, всякой фоновой загрузки во всех этих дополнительных операционках.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А привычка очень быстро вырабатывалась. Мы программы часто даже не писали, сразу набирали в редактор из головы.
Боюсь спросить, сколько вам лет? Наверное такое даже не в 80-х было, а не позже 70-х.
Здравствуйте, IID, Вы писали:
IID>а наносекунды ты чем будешь засекать ? таймером, которому доверия нет
А ему и не нужно доверия. Задача в том, чтобы определить, соблюдаются ли в системе все известные временнЫе соотношения, характерные для определенных моделей железа. Еще можно проверить наличие недокументированных особенностей (состояние резервных регистров/разрядов и т.п.). Нарушение каких-то из этих соотношений будет означать, что в системе что-то не так — или неисправная физическая, или не полностью виртуализованная. А что именно в виртуализованной системе работает не так — таймер, контроллер или шина — уже не столь важно.
Здравствуйте, jamesq, Вы писали:
J>сколько вам лет?
Не столь и много — 57.
J>Наверное такое даже не в 80-х было, а не позже 70-х.
Я начинал в 80-м. А сотрудники нашей кафедры работали на БЭСМ-6 в одном из НИИ где-то до середины 90-х. Примерно до тех же времен в другом НИИ, с которым я сотрудничал, работали на какой-то из ЕС ЭВМ, пока не заменили ее на несколько PC AT. Основная проблема с заменой была даже не в деньгах, а в программах — для БЭСМ-6 было много программ на экзотических языках или местных диалектах Fortran/Algol, для ЕС — на PL/1 и COBOL. Переносить их на PC было то еще удовольствие.
Часто он появлялся из-за надобности плавучки, но не обязательно.
