Была бы какая-либо точка в разработке ЦП, который мог обработать IL непосредственно?
Если вы хотите использовать LocalTime и ChronoUnit классы Java 8:
String sTimeIn = "23:15";
String sTimeOut = "1:30";
LocalTime timeIn = LocalTime.parse(sTimeIn, DateTimeFormatter.ofPattern("H:m"));
LocalTime timeOut = LocalTime.parse(sTimeOut, DateTimeFormatter.ofPattern("H:m"));
long dif = ChronoUnit.MINUTES.between(timeIn, timeOut);
if (dif < 0)
dif += 24 * 60;
long sumHour = dif / 60;
long sumMinute = dif % 60;
System.out.println(sumHour + ":"+ sumMinute);
или в формате HH:mm:
System.out.println(String.format("%02d", sumHour) + ":"+ String.format("%02d", sumMinute));
напечатает: [118 ]
02:15
5 ответов
Подобная технология действительно существует для Java - ARM делает диапазон центральных процессоров, которые могут сделать это, они называют это их технологией "Jazelle".
Однако операции, представленные кодами операций .net IL, только четко определены в сочетании с информацией о типе, держался стек, не самостоятельно. Это - существенное различие от байт-кода Java и сделало бы намного более трудным создать разумные аппаратные средства для выполнения IL.
Кроме того, IL предназначается для компиляции к заключительной цели. Большинство бэкэндов, которые выкладывают IL, делает очень мало оптимизации, имея целью вместо этого сохранять семантическое содержание для проверки и оптимизации на заключительном шаге компиляции. Даже если аппаратные проблемы могли бы быть преодолены, результат почти наверняка все еще будет медленнее, чем достойная оптимизация JIT.
Так, для подведения: в то время как это не невозможно, это было бы непропорционально твердо по сравнению с другой архитектурой и достигнет малого.
Я не думал бы так по двум причинам:-
- Если бы у Вас были аппаратные средства, обрабатывающие IL, что аппаратные средства не смогли бы выполнить более новую версию IL. С JIT Вам просто нужен новый JIT затем, существующие аппаратные средства могут выполнить более новый IL.
- IL прост и разработан, чтобы быть аппаратным агностиком. IL должен был бы стать намного более сложным, чтобы позволить этому описать операции самым эффективным способом для получения где угодно близко к производительности существующего машинного кода. Но это означало бы, что IL будет намного более тверд работать не на IL определенные аппаратные средства.
Я сказал бы "нет".
Фактические инструкции по машинному языку, которые должны работать на компьютере, ниже находятся на одном уровне, чем IL. IL, например, действительно не описывает, как вызовы методов должны быть выполнены, как регистрами нужно управлять, как к стеку нужно получить доступ, или любые другие из деталей, которые необходимы на уровне машинного кода.
Получение машины распознать IL непосредственно было бы, поэтому, простое перемещение вся логика JIT-компиляции из программного обеспечения в аппаратные средства.
Это сделало бы целый процесс очень твердым и неизменным.
При наличии машинного языка на основе возможностей машины и промежуточного языка на основе получения намерения программиста, Вы получаете намного лучшую систему. Люди, определяющие машину, могут сконцентрироваться на определении эффективной архитектуры ЭВМ, и люди, определяющие систему IL, могут сфокусироваться на вещах как выразительность и безопасность.
Если бы и поставщики инструмента и поставщики оборудования должны были использовать то же самое представление для всего, то инновациям или в аппаратном пространстве или в пространстве инструмента препятствовали бы. Так, я говорю, что они должны быть отдельными друг от друга.
Это не новая идея - то же самое было предсказано для Java, и LISP-компьютеры были даже на самом деле реализованы.
Но опыт с теми шоу, что это не действительно полезно - путем разработки центральных процессоров специального назначения, Вы не можете извлечь выгоду из усовершенствований "традиционных" центральных процессоров, и Вы очень вероятно не можете победить Intel в их собственной игре. Кавычка из статьи Wikipedia иллюстрирует это приятно:
более дешевые настольные ПК скоро смогли запустить программы Lisp еще быстрее, чем LISP-компьютеры без использования аппаратных средств особого назначения.
Перевод с одного вида машинного кода другому на лету является хорошо понятой проблемой, и столь распространенный (современные центральные процессоры CISC даже делают что-то как то, что внутренне, потому что они - действительно RISC), что я полагаю, что мы можем принять, это делается достаточно эффективно, что предотвращение его не приводит к значительным преимуществам - не, когда это означает, что необходимо отделить себя от состояния в традиционных центральных процессорах.
Вы кажетесь немного смущенными как работа ЦП. Блок не является отдельным языком из машинного кода. Это - просто другое (текстовое) представление его.
Ассемблерный код является просто последовательным списком инструкций, которые будут выполняться. И машинный код является точно тем же самым. Каждая инструкция, поддерживаемая ЦП, имеет определенную комбинацию двоичных разрядов, которые заставляют это выполняться, и это также имеет текстовое имя, которое можно использовать в ассемблерном коде.
Если я пишу add $10, $9, $8 и выполненный это через ассемблер, я получаю машинный код для добавить инструкции, принимая значения в регистрах 9 и 8, добавляя их и храня результат в регистре 10.
Существует от 1 до 1 отображения между ассемблерным и машинным кодом.
Также нет никаких "вызовов API". ЦП просто читает из адреса X и соответствует последующим битам против всех инструкций, которые он понимает. После того как это находит инструкцию, которая соответствует этой комбинации двоичных разрядов, это выполняет инструкцию и идет дальше для чтения следующей.
То, что Вы спрашиваете, в некотором смысле невозможно или противоречие. IL обозначает Промежуточный язык, то есть, своего рода псевдокод, который испускается компилятором, но еще не был переведен в машинный код. Но если бы ЦП мог бы выполнить это непосредственно, то это больше не было бы промежуточным, это будет машинный код.
Таким образом, вопрос становится "действительно ли Вашим кодом IL, лучшее, более эффективное представление программы, чем машинный код поддержки ЦП теперь?"
И ответ наиболее вероятен нет. MSIL (я предполагаю, что это - то, что Вы подразумеваете под IL, который является намного более общим термином), разработан, чтобы быть портативным, простым и последовательным. Каждый язык.NET компилирует в MSIL, и каждая программа MSIL должна смочь быть переведенной в машинный код для любого ЦП где угодно. Это означает, что MSIL должен быть общим и абстрактным и не сделать предположения о ЦП. Поэтому насколько я знаю, это - чисто стековая архитектура. Вместо того, чтобы сохранить данные в регистрах, каждая инструкция обрабатывает данные на вершине стека. Это - хорошая чистая и универсальная система, но это не очень эффективно, и не переводит хорошо в твердую структуру ЦП. (В Вашем замечательном небольшом высокоуровневом мире можно притвориться, что стек может вырасти свободно. Чтобы ЦП получил быстрый доступ к нему, он должен быть сохранен в некоторой маленькой, быстрой памяти на микросхеме с конечным размером. Таким образом, что происходит если Ваше нажатие программы слишком много данных по стеку?)
Да, Вы могли сделать ЦП для выполнения MSIL непосредственно, но что Вы получите? Вам больше не было бы нужно к коду JIT перед выполнением, таким образом, в первый раз Вы запускаете программу, это запустилось бы немного быстрее. Кроме этого, хотя? После того как Ваша программа MSIL была JIT'ed, она была переведена в машинный код и выполнения как эффективно, как будто она была записана в машинном коде первоначально. Байт-код MSIL больше не существует, просто ряд инструкций, понятых под ЦП.
На самом деле Вы вернулись бы, где Вы были перед.NET. Неуправляемые языки компилируются прямо в машинный код, точно так же, как это было бы в Вашем предложении. Единственная разница - то, что неуправляемый код предназначается для машинного кода, который разработан разработчиками ЦП для подхождения для выполнения на ЦП, в то время как в случае, это предназначалось бы для машинного кода, это разработано разработчиками программного обеспечения, чтобы быть легким перевести в и от.