Где идет морфинг кода?

Линус Торвальдс работал на процессорную компанию Transmeta. Процессор, который они сделали, был объектом на основе RISC в ядре. Если я правильно помню, идея заключалась в том, что ядро запускало произвольный и обновляемый "уровень эмуляции процессора" (может быть x86, powerpc и т.д.), Который переводил коды операций высокого уровня в набор инструкций ядра RISC.

Что случилось с этой идеей и какими, на ваш взгляд, были плюсы, минусы и ситуации, когда такой подход мог иметь преимущество (с точки зрения программирования)?

Ответ 1

Компания не делала так, как ожидали, и в конечном итоге была приобретена Novafora для энергосберегающих технологий. (http://www.novafora.com/pr01-28-09.html)

Из всех учетных записей, о которых я знаю, технология просто не конкурировала с существующими системами. Они значительно отставали от своих показателей. Кроме того, хотя, возможно, возможно было поставить другого переводчика поверх своего дизайна VLIW, я не знаю о каких-либо продуктах, которые они создали. Я не помню, как чип Crusoe может принять альтернативный "перевод" микрокода.

Мне лично принадлежало устройство, в котором использовался процессор Crusoe, и, несмотря на то, что он, безусловно, обеспечивал работу от батареи, производительность устройства была мрачной. Некоторая часть вины, вероятно, может быть выровнена на специальной версии Windows, которую она использовала, но она все еще была медленной.

В лучшем случае это было хорошо для портативного удаленного рабочего стола.

IMHO, технология имеет те же преимущества, что и программные VM, такие как .Net и JVM:

Положительным моментом является то, что вы, вероятно, можете ускорить код быстрее с помощью аппаратное решение (например, IBM это Java-ускорители) чем чистая программа JIT.
Недостатком является то, что вы никогда не получаете производительность, выполняемая процессорами нативный код get.

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

Другим примером такого рода технологий могут быть FPGA, которые могут быть запрограммированы для эмуляции на уровне схемы различных типов процессоров или исходных схем. Я считаю, что некоторые системы Cray могут поставляться с "узлами ускорителя" такого типа.

Ответ 2

С одной стороны, большинство процессоров CISC внутренне преобразуют свои коды операций в микропроцессы, аналогичные операциям RISC. Конвейерная обработка и несколько ядер закрывают разрыв на RISC-процессорах до такой степени, что между ними небольшая разница, если таковая имеется. Если вам нужна перекрестная совместимость с источником C или другим интерфейсом, вы можете использовать LLVM. http://llvm.org/

Ответ 3

Очевидные профи:

Возможность запуска любой ОС (просто переключите эмуляцию процессора на то, что необходимо)
Возможность (с поддержкой ядра, конечно) запуска исполняемых файлов для разных архитектур на одном процессоре/ОС без поддержки программного обеспечения.

Очевидный con:

Дополнительный уровень эмуляции == более накладные расходы == более быстрый процессор, необходимый для получения эквивалентной производительности для ВСЕГО.

Ответ 4

Я бы сказал, что сокращение затрат идет с количеством, поэтому что-то вроде чипа Transmeta должно продавать большой объем, прежде чем он сможет конкурировать по цене с существующими чипами x86 с высоким объемом.

Если я помню, точка чипа Transmeta заключалась в том, что это была низкая мощность. Имея меньше кремниевых затворов, чтобы переворачивать назад и вперед, каждый такт экономит энергию. Морфинг кода был таким образом, что вы могли запускать сложный набор команд (CISC) на микросхеме RISC с низким энергопотреблением.

Первый процессор Transmeta, Crusoe, не очень хорошо справился с проблемами даже при работе с программным обеспечением. Их второму процессору, Efficeon, удалось использовать меньше энергии, чем Intel Atom (в той же категории производительности), и работать лучше, чем Centrino в той же мощности.

Теперь, глядя на это с точки зрения программного обеспечения и гибкости, как и вы, Code Morphing - это всего лишь форма компиляции Just-In-Time со всеми преимуществами и недостатками этой технологии. Ваш x86-код по существу работает на виртуальной машине и эмулируется другим процессором. Самое большое преимущество виртуализации прямо сейчас - это возможность совместного использования одного процессора между многими виртуальными машинами, поэтому у вас меньше рабочих циклов процессора, что является более эффективным (стоимость оборудования и стоимость энергии).

Итак, мне кажется, что преобразование кода, как и любая форма виртуализации, заключается в более эффективном использовании ресурсов.

Ответ 5

Для другого подхода к виртуализации x86 ISA с аппаратным обеспечением вы можете прочитать о Loongson 3.

Ответ 6

Большинство современных процессоров фактически реализуют свои наборы команд, используя microcode. Этому есть много причин, включая проблемы совместимости, но есть и другие причины.

Различие между "аппаратным" и "программным обеспечением" на самом деле сложно сделать. Современные виртуальные машины, такие как JVM или CIL (.NET), также могут быть реализованы в аппаратном обеспечении, но это, вероятно, просто будет сделано с использованием микрокода.

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

В операционной системе и системных библиотеках также есть дополнительные уровни абстракции. Но наличие этих уровней только делает систему "более медленной", если не нужны функции, которые они предоставляют (т.е. Планирование потоков, выполняемое ОС). Нелегкая задача - заставить свой собственный планировщик, зависящий от конкретной программы, победить тот, который находится в ядре Linux.