Если я это правильно понимаю:
Текущие компании, занимающиеся разработкой процессоров, такие как AMD и Intel, имеют свои собственные коды API (язык ассемблера) как то, что они видят как язык 2G поверх машинного кода (язык 1G)
Было бы возможно или желательно (производительность или иное) иметь ЦП, который выполнял бы обработку ИЛ на нем ядро вместо текущих вызовов API?
Аналогичная технология существует для Java - ARM делает целый ряд процессоров, которые могут это сделать, они называют это своей технологией "Jazelle".
Однако операции, представленные кодами операций .net IL, только четко определены в сочетании с информацией типа, хранящейся в стеке, а не сами по себе. Это существенное отличие от Java-байт-кода, и было бы намного сложнее создать разумное оборудование для выполнения IL.
Кроме того, IL предназначен для компиляции к конечной цели. Большинство задних концов, которые выплевывают IL, делают небольшую оптимизацию, стремясь вместо этого сохранить семантический контент для проверки и оптимизации на заключительном этапе компиляции. Даже если проблемы с оборудованием могут быть преодолены, результат почти наверняка будет медленнее, чем приличный оптимизирующий JIT.
Итак, подведем итог: хотя это не невозможно, это было бы непропорционально тяжело по сравнению с другими архитектурами, и это бы мало.
Кажется, вы немного смущены тем, как работает ЦП. Сборка не является отдельным языком из машинного кода. Это просто другое (текстовое) представление.
Код сборки - это просто последовательный список инструкций, которые должны быть выполнены. И машинный код - это точно то же самое. Каждая инструкция, поддерживаемая процессором, имеет определенный битовый шаблон, который заставляет его выполнять, а также текстовое имя, которое вы можете использовать в коде сборки.
Если я пишу add $10, $9, $8 и запускаю его через ассемблер, я получаю машинный код для инструкции add, беря значения в регистрах 9 и 8, добавляя их и сохраняя результат в регистре 10.
Существует сопоставление от 1 до 1 между ассемблером и машинным кодом.
Также нет "вызовов API". Процессор просто считывает с адреса X и сопоставляет последующие биты со всеми инструкциями, которые он понимает. Когда он найдет инструкцию, которая соответствует этому битовому шаблону, он выполняет инструкцию и переходит к следующей следующей.
То, что вы просите, в некотором смысле невозможно или противоречиво. IL обозначает промежуточный язык, то есть своего рода псевдокод, который испускается компилятором, но еще не был переведен в машинный код. Но если CPU мог бы выполнить это напрямую, то он больше не будет промежуточным, это будет машинный код.
Таким образом, вопрос становится "является ли ваш код IL лучшим и более эффективным представлением программы, чем машинный код, поддерживаемый процессором сейчас?"
И ответ, скорее всего, нет. MSIL (я полагаю, что то, что вы подразумеваете под IL, которое является гораздо более общим термином), предназначено для портативного, простого и последовательного. Каждый язык .NET компилируется в MSIL, и каждая программа MSIL должна быть переведена в машинный код для любого процессора в любом месте. Это означает, что MSIL должна быть общей и абстрактной и не делать предположений о процессоре. По этой причине, насколько я знаю, это чисто стековая архитектура. Вместо хранения данных в регистрах каждая команда обрабатывает данные в верхней части стека. Это хорошая чистая и универсальная система, но она не очень эффективна и не очень хорошо подходит для жесткой структуры процессора. (В вашем прекрасном маленьком мире высокого уровня вы можете притворяться, что стек может свободно расти. Для того, чтобы CPU быстро получал доступ к нему, он должен храниться в небольшой, быстрой встроенной памяти с конечным размером. если ваша программа нажимает слишком много данных на стек?)
Да, вы могли бы заставить CPU выполнять MSIL напрямую, но что бы вы получили? Вам больше не понадобится JIT-код перед выполнением, поэтому при первом запуске программы он запускается немного быстрее. Кроме того, хотя? После того, как ваша программа MSIL была JIT'ed, она была переведена на машинный код и работает так же эффективно, как если бы она была написана в машинный код изначально. Байт-код MSIL больше не существует, а всего лишь ряд инструкций, понятных процессору.
Фактически, вы вернетесь туда, где были до .NET. Неконтролируемые языки скомпилированы прямо в машинный код, как это было бы в вашем предложении. Единственное различие заключается в том, что не управляемый код предназначен для машинного кода, разработанного разработчиками CPU, подходящего для исполнения на процессоре, в то время как в вашем случае он будет нацелен на машинный код, разработанный разработчиками программного обеспечения, легко переносить и из.
Это не новая идея - то же самое было предсказано для Java, а Lisp машины были даже реализованы.
Но опыт с этими показателями показывает, что это не очень полезно - при разработке специализированных процессоров вы не сможете воспользоваться преимуществами "традиционных" процессоров, и вы, скорее всего, не сможете победить Intel в своей игре. Цитата из статьи в Википедии прекрасно иллюстрирует это:
более дешевые настольные ПК вскоре смогли запускайте программы Lisp даже быстрее, чем Lisp, без использования специального оборудования.
Перевод с одного типа машинного кода на другой "на лету" - это хорошо понятая проблема и так распространена (современные процессоры CISC даже делают что-то подобное внутри, потому что они действительно RISC), и я считаю, что мы можем предположить, что это сделано достаточно эффективно, чтобы избежать этого, не приносит существенных преимуществ, а не тогда, когда это означает, что вам нужно отделить себя от современного уровня техники в традиционных процессорах.
Я бы сказал, нет.
Фактические инструкции машинного языка, которые должны выполняться на компьютере, ниже уровня IL. IL, например, на самом деле не описывает, как должны обрабатываться вызовы методов, как управлять регистрами, как должен быть доступ к стеку, или любые другие детали, которые необходимы на уровне машинного кода.
Получение машины для распознавания IL напрямую могло бы, таким образом, просто переместить всю логику компиляции JIT из программного обеспечения в аппаратное обеспечение.
Это сделает весь процесс очень жестким и неизменным.
Используя машинный язык, основанный на возможностях машины, и промежуточный язык, основанный на улавливании намерений программиста, вы получаете гораздо лучшую систему. Люди, определяющие машину, могут сосредоточиться на определении эффективной компьютерной архитектуры, а люди, определяющие систему IL, могут сосредоточиться на таких вещах, как выразительность и безопасность.
Если и поставщики инструмента, и поставщики оборудования должны были использовать одинаковое представление для всего, было бы затруднено внедрение в аппаратное пространство или пространство инструмента. Итак, я говорю, что они должны быть отделены друг от друга.
Я бы не подумал по двум причинам: -