На чем только уже не запускали Doom. Мы же будем запускать Linux. Да не где-нибудь, а на Python. Да-да, прямо внутри него, где в качестве среды выполнения будет выступать интерпретатор Python. Ну как... Не будем пытаться переписать ядро и другие части Linux на этот язык, а попробуем написать (точнее портировать) виртуальную машину на Python и уже в ней запускать ОС.

Начнем с позитивного, а именно с плюсов такого решения.

– Можно будет запустить Linux вообще везде, где есть интерпретатор Python.

– Можно использовать как бенчмарк конкретного интерпретатора.

– Веселимся, пока все это пишем и отлаживаем. Пожалуй, это самый главный плюс.

Минусы: будет работать оооочень не быстро (ну логично же).

Немного технических подробностей. Внезапно поработаем с нейросетями, посмотрим, что получится и насколько быстро будет работать.

Статья не претендует на какие-то сильно новые знания, и все это было сделано Just for Fun и ради эксперимента.

Приступаем!

На старт

В качестве референса, из которого родилась эта идея, была уже не самая свежая новость. Смотрим, что к чему, и идем по самому простому пути, а именно пытаемся сделать то же самое, но с другого бока. 

Итак, эмулятор RISC-V, который умеет запускать образ Linux, у нас имеется. Первый — это простенькая виртуальная машина с поддержкой 32х-битного RISC-V процессора без MMU и прочих аппаратных «излишеств». Второй — это собранный для этой архитектуры такой же простенький Linux без поддержки MMU. Осталось дело за малым: портировать первый с Си на Python.

Можно, конечно, руками переписать на красивый код, но как будто это слишком рутинная операция в наше прогрессивное время. Попробуем вооружиться нейросетями, и пусть они впахивают, а не мы. Для перевода кода из одного языка программирования в другой существует, например, такой онлайн конвертер (не реклама, если что, одно из первых, что попалось в Google). Скармливаем наш код этому AI-конвертеру иии... он выплевывает наружу что-то вполне корректное. С кучей оговорок, конечно же, но то, что этот код похож на оригинал, уже радует. Не совсем красивый, каким мог бы быть. Например, рабочее, но сомнительное решение:

	elif (ir >> 12) & 0x7 == 1:
    	if rs1 != rs2:
        	pc = immm4
	elif (ir >> 12) & 0x7 == 4:
    	if rs1 < rs2:
        	pc = immm4
	elif (ir >> 12) & 0x7 == 5:
    	if rs1 >= rs2:
        	pc = immm4
	elif (ir >> 12) & 0x7 == 6:
	...

Ну да ладно, сами виноваты, что не пишем код сами. Главное, чтобы было корректно. А оптимизацию и рефакторинг оставим на потом.

Итак, у нас имеется переведенный с Си на Python код. Уже неплохо.

Внимание

С первой попытки ничего, конечно же, не заработало. «Переводчик» удалил почему-то части кода, которыми не знает, как пользоваться (а скармливал я ему по одному файлу). Быстренько допиливаем и запускаем.

Разбираться, где еще нейросеть недосмотрела, и вникать в тонкости работы архитектуры не хочется, поэтому пытаемся отлавливать ошибки по ходу работы. А по ходу дела начинают происходить все более изощренные баги, особенно в работе нашего виртуального RISC-V.

Сделаем такой трюк. Считаем, что вся загрузка ядра — это очень детерминированный процесс. Поэтому, сколько бы раз мы ни запускали ОС, мы должны получать на каждом шаге загрузки всегда одно и то же состояние системы. Состояние нашего эмулятора будет обусловлено всего двумя факторами:

– внутренними регистрами виртуального процессора;

– памятью виртуального процессора.

Вроде больше ничего. Плюс, конечно же, состояние периферии, но ее не так много и на начальном этапе загрузки она не используется.

Поскольку у нас есть оригинальная виртуальная машина на Си, которая точно так же работает, давайте логировать состояние системы там и одновременно в нашем эмуляторе на Python. Затем сравним эти логи и посмотрим, на каком шаге пошли отличия. Если такие отличия есть, нужно уже отлаживать конкретно этот шаг эмулятора.

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

Быстро дописываем код для логирования и там и там, ну и далее по циклу: запускаем-логируем-смотрим-дорабатываем и опять запускаем-логируем-смотрим-дорабатываем, пока все не запустится. Благо, в RISC-V команд процессора не так много и, соответственно, ошибок тоже не так много можно допустить.

Самые частые ошибки, которые сделал AI-переводчик следующие:

– Ошибки переполнения. Так как Int в Python условно безграничный, он может хранить бо'льшие значения, чем RISC-V (помним, что последний у нас 32х-битный). Поэтому нужно искусственно расставлять ограничения на длину числа после операций с регистрами.

– Отступы не всегда корректны в функциях, а в Python-e это важно. Просто молча правим.

– Некорректное поведение «переводчика». Например, это: 

uint32_t * dtb = (uint32_t*)(ram_image + dtb_ptr);
if( dtb[0x13c/4] == 0x00c0ff03 )

он преобразует в это:

  dtb = struct.unpack('<I', ram_image[dtb_ptr:dtb_ptr+4])[0]
  if dtb == 0x00c0ff03:

Ошибку, думаю, показывать не надо. В таких случаях думаем, что да как, после чего так же молча правим.

Марш

Через некоторое время отладки и запусков видим:

Ура, оно живое! На удивление, наш Linux достаточно быстро запускается, что не может не радовать.

Надо бы протестировать, как быстро такое решение работает в более конкретных цифрах. В образе Linux заботливо оставлен Coremark для тестирования производительности. Запустим его пару раз и сравним скорость работы Linux в виртуальной машине на Python и на Си. А еще, ради интереса, протестируем пару нестандартных Python интерпретаторов/компиляторов.

Итого, сравнительная табличка производительности для coremark:

Не густо. Python не быстрый. Этого стоило ожидать. Улучшать и оптимизировать код нашей Python-виртуальной машины можно и, соответственно, улучшить результат, но примем результат, какой он есть.

Финиш

Эта статья получилась из разряда «что получится, если…». AI-переводчик сэкономил немало времени на разработку этого всего, но и добавил другой работы по исправлению. Но теперь всё позади, можем смело запускать Linux на Python. Пусть и с ограничениями по скорости, да и вообще, у нас виртуальная машина и Linux без поддержки MMU, но можем же.

В самом лучшем случае (при помощи JIT компилятора PyPy) такое решение почти в 183 раза хуже по производительности нативной виртуальной машины. И промолчим, что вообще-то можно нативно скомпилировать и запустить Linux на реальном железе и будет еще быстрее и разница будет еще существеннее. Но зато, наше решение полностью портативное и может запускаться в любой (или почти любой) Python-среде исполнения. А еще получилось крайне компактно — всего порядка 900 строк рабочего кода. Все исходники и инструкция по запуску, конечно же, есть на github.