Чи можна віртуалізувати будь-який процесор на будь-якому іншому процесорі?

Нещодавно я отримав Raspberry Pi і прочитав багато публікацій у блогах про проекти на ньому, і хотів спробувати декілька з них. Але я також читав, що SD-картки не мають великої тривалості життя, якщо ми (повторно) пишемо на нього багато разів. Тому я хотів спробувати зображення для проекту Pi на віртуальній ОС (бажано з Virtualbox).

Тож я хотів знати, чи можна мені віртуалізувати процесор ARM на власному процесорі ноутбука. Для запису я запускаю Ubuntu 14.04 і uname -aвідповідає:

Linux Laptop 3.13.0-49-generic #83-Ubuntu SMP Fri Apr 10 20:11:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux`

Але як мені цікаво, я хотів би знати, чи можна віртуалізувати будь-який процесор на будь-якому іншому процесорі. Це щось пов'язане з обладнанням чи програмним забезпеченням?

Дуже дякую.

Для питання про RPi, погляньте на цю тему (по суті, ви можете використовувати щось на зразок QEMU для запуску зображень).

Щоб відповісти на головне питання:

Чи можна віртуалізувати будь-який процесор на будь-якому іншому процесорі?

Так (певною мірою), однак, це може бути не настільки ефективно, як ви думаєте. І слід зазначити, що тип віртуалізації VirtualBox / VMWare відрізняється від того, про що ви запитуєте, що є насправді Is it possible to EMULATE any CPU on any other CPU?.

Процесори - це апаратні компоненти, які мають специфічний набір інструкцій (також відомий як оп-коди), з’єднані з ними; ці оп-коди - це конкретні числові значення, які можна перевести на електричному рівні, щоб процесор насправді "щось робив".

Коли програмне забезпечення написане для того, щоб сказати процесору "зробити щось" (наприклад, калькулятор), програмне забезпечення повинно бути побудовано (орієнтоване) на певний процесор. Тобто моє програмне забезпечення повинно бути скомпільоване (перекладене) та зібране таким чином, щоб машинні інструкції можна було зрозуміти машиною, на якій я запускаю своє програмне забезпечення, інакше, якщо воно взагалі працює, я не можу отримати точних результатів, Я чекаю. Інструкції по збірці (оп-коди) для чогось типу 2 + 2 на ARM можуть не точно відповідати інструкціям по збірці на PIC або FPGA, і те, що я поверну, було б сміттям (знову ж, якби воно працювало).

Кожен процесор 'робить щось' дещо інакше, як багато я можу писати англійською мовою, щоб передати свої думки вам, я також міг би передати ті самі думки іспанською або японською мовами, хоча мені доведеться передати їх зовсім по-іншому через не лише синтаксичні відмінності в англійській / іспанській / японській мовах, але відмінності в тому, як ці мови також розібрані в контексті. Якщо ви та я розмовляли (проти письмового спілкування), а ви розмовляли лише японською, а я іспанською, то нам потрібен був перекладач, який вільно володіє обома мовами, щоб правильно спілкуватися, хоча це було б повільніше, ніж пряме спілкування, оскільки ми потрібно, щоб наші мови були правильно розібрані, щоб нічого не «втрачалося при перекладі».

Це те саме поняття з процесором "віртуалізація / емуляція". Якщо ви хочете запускати додатки, які не були побудовані для центрального процесора, на якому ви працюєте (тобто я хочу запустити програмне забезпечення ARM на моєму ПК x86), то програмі потрібно взяти збірку ARM і перевести на збірку x86, щоб дзвінок до draw word on screen, а не виклик для erase RAM location X.

Ось чому це не обов'язково неможливо належним чином емулювати будь-який процесор на будь-якому іншому процесорі (якщо він взагалі не може наслідувати x86 на PIC як такому). Процесор робить набагато більше, ніж просто «стискає номери», і вони роблять все це «більше», ДУЖЕ швидко, і багато вимагають, щоб терміни цього все були точними. Емулюючи процесор, ви по суті додаєте шар перекладу між програмним забезпеченням та обладнанням. Додавання цього шару може додати значну кількість часу на виконання інструкцій через те, скільки додаткових інструкцій може знадобитися виконувати. Цей додатковий час може зайняти стільки часу, що програмне забезпечення стане невідповідним або взагалі непридатним (наприклад, грати у відеоігри зі швидкістю 1 кадр в секунду, впевнений, що ви можете це зробити, але для написання "прес-запуску" знадобиться 2 хвилини.

Слід зазначити, що якщо в апаратному забезпеченні (ЦП) вбудований той самий набір інструкцій, він повинен "робити те ж саме", як призначений інший набір інструкцій; тобто (проблема з патентом / ліцензією вбік) Intel може вирішити додати набір інструкцій для процесора ARM в рядок CPU x86_64, щоб ви могли потенційно запускати бінарні файли ARM безпосередньо на цьому процесорі, але вони все одно повинні мати архітектуру 'робити', як це робить архітектура ARM ', або висновок може бути неточним.

Так, можливо, можна емулювати один тип процесора на інший тип процесора, але залежно від того, як / що імітується, це може бути настільки повільним, що вважатиметься нездійсненним або може бути нерозрізненим з людської точки зору (тобто суб'єктивно це "настільки ж швидкий", як і на вбудованому обладнання, але технічно це не так).

Я сподіваюся, що це може допомогти додати трохи ясності.

Ви можете використовувати QEMU для емуляції будь-якого процесора як віртуальної машини у вікні Ubuntu.

з їх головної сторінки -

QEMU - це універсальний емулятор та віртуалізатор із відкритим кодом.

Використовуючи як емулятор машини, QEMU може запускати ОС та програми, створені для однієї машини (наприклад, дошку ARM) на іншій машині (наприклад, на власному ПК). Використовуючи динамічний переклад, він досягає дуже хороших показників.

Існує особлива стаття про налаштування його тут , але якщо ви шукаєте «Убунту в Qemu малини» це дасть величезну кількість відповідей , щоб ви на правильному шляху.

Остання частина вашого запитання - зовсім інший звір! і те, що Алан Тьюрінг дуже багато роздумував. Це не є відповіддю - тому що я ніде не достатньо розумний, щоб все це підбити, - але варто почати з Універсальної машини Тюрінга, яка була його підходом до цього точного питання.