> i8080 -- это азы, но к реальной жизни имеет уже весьма смутное
> представление, поэтому сейчас речь идёт только о 386+.

Да как сказать? Годы шли, а общие идеи в основе работы микропроцессоров никуда не делись. Развили хорошо. Но большинство улучшений - не такая уж новость, просто все и сразу было сложно сделать. Те кто владеет текущим state of art - обычно могут предвидеть развитие на годы вперед.

Пример того что я считаю профессионализмом электронщика: в эпоху первых пентиумов и PCI, один человек, посмотрев на USB, сказал что в будущем будут рулить скоростные последовательные шины с дифференциальным сигналом, похожие по смыслу. Хотя USB 1.1 смотрелся смешно на фоне, например, PCI. Годы шли. Появился PCI-E, SATA, USB3, HDMI, DisplayPort... И у всех них оказалось кое-что общее.

> pyPC -- это исключительно химерный компьютер рождённый моей головой. Поэтому ни КВМ,
> ни ВиртуалБокс его никогда не запустят. В-общем, в этом вся затея.

Тот же QEMU - тоже изначально задуман как виртуальный компьютер, с виртуальной периферией. Просто теперь он "хорошо оптимизированный". Поэтому когда возможно - не то что транслируют, а просто выполняют большинство команд напрямую на системном проце (по сути это и называется KVM), обрабатывая только исключения (работу с железом, чего в юзермоде конечно же не положено) в гипервизоре (для чего требуется выносок в ядре хостовой системы). И даже решили что нафиг эмулировать реальные железки и регистры. Пусть ОС в гуесте знает что это - виртуализатор. И использует драйвер, который умеет сбагривать I/O на хост короткими и быстрыми путями. Это называется virtio. В результате оно разогналось до скоростей сравнимых с реальной железякой, перестав быть забавной игрушкой.

> Трансляция в нативные команды на лету - это круто для меня,
> до такого вряд ли дорасту с вероятностью 95%.

Это один из немногих методов выполнить чужой код с вменяемой скоростью. Хотя для действительно приличной скорости все серьезные виртуализаторы выполняют большинство команд на системном проце напрямую и обманывают операционку, запущенную как user mode процесс, подтасовывая обработку исключений при привелигированных командах так, что kernel-mode код гуеста не замечает того что это user-mode, а не kernel-mode.

По поводу таких оптимизаций в серьезно настроенных виртуализаторах сдулись даже севые, но не оптимизированные в эти направления виртуализаторы по типу bochs. Они были неприемлимо тормозными, про них при удобном случае все забыли.

> будь здоров.

А это сколько процентов от производительности host? KVM может более 90% при счете и доступе к памяти, сохраняя все плюсы виртуализатора. Т.е. например пнутый в нем какой-нибудь "7z b" (бенчмарк в архиваторе 7zip) покажет процентов 90 того что он показывает на железке. Вот это уже интересно. Но это потребовало нехилой оптимизации и ряда трюков, в сумме энное количество народа пахало над доведением этого до кондиции несколько лет.

> Что касается моих тестов -- замер времени либо по исполнению 5000 циклов,
> либо методом timeit. Разница в результатах - смешная. Так что, тест
> вполне объективен.

Не знаю что есть "методом timeit", но в целом часто дергать запросы "сколько времени?" в процессе бенчмарков в тугом цикле не следует, а если кто так делает - это не в его пользу говорит, т.к. показывает что человек полез бенчмаркать, не умея это делать и будучи не в курсе про resolution таймеров, оверхед от вызовов и прочем. Да и первый вопрос который возникает: что бенчмаркано и зачем? Какие-то реально существующие программы оптом выполняют подобный код? Нормальные бенчмарки или пытаются забенчмаркать какой-то общий аспект работы системы (например, "скорость доступа к памяти") или пытаются прогнать какой-то практически-значимый алгоритм (например, "сколько времени займет хеширование 10 мегабайтов с использованием sha-1?"). А по такому коду не понятно что являлось целью бенчмарка. Доказать всему миру что "питон не тормозит ну хоть где-то"?