О байт-коде

Для eval - JIT. Интроспекция реализуема и со статической компиляцией.

Реализации с JIT никем не используются.

Потому что пока еще нормально не работают.

＞он просто не нужен

Зачехлить орудия и не двигаться. За вами уже выехала бригада санитаров.

Нет. Т.к. байт-кодом в простонародии называют всё, что не исходник и не нативный код.

Ъ-шитый код же.

часто компилируется в нативный - man JIT

JIT-компилятор сгенерирует мне standalone-бинарник?

JIT-компилятор сгенерирует мне standalone-бинарник?

любая сколько-нибудь полезная программа зависит от рантайма. у тебя все пакеты в системе слинкованы статически?

JIT-компилятор сгенерирует мне standalone-бинарник?

Легко.

Нет. Т.к. байт-кодом в простонародии называют всё, что не исходник и не нативный код.

Круто. Сохранил, как одно из «альтернативных» определений байт-кода. Насчёт копырайта не волнуйся, отметил твоё авторство. :)

Да я и не говорю, что зависимость от рантайма это плохо :) Просто, ТС, имхо, имел в виду компиляцию в привычном смысле слова.

Что мне надо передать JVM для этого?

AOT компиляция статическая, ничего не анализируется, код генерируется под обобщенную аппаратную платформу. В случае JIT есть возможность, во-первых, адаптивно подстраивать сгенерированный код под условия выполнения, во-вторых — использовать все возможности именно того железа и окружения, на котором программа выполняется в данный момент.

байт-кодом в простонародии называют всё, что не исходник и не нативный код

То есть код ARM'а на x86 будет байткодом и наоборот? :)

Или код JVM не будет байткодом, когда работает на Java-процессоре? :)

Ну и раз тут заговорили о jvm и шарпах. Простая генерация нативного кода не даст такую же производительность, как с++. Язык остается безопасным, проводятся все те же проверки типов, исключения, создание объектов в куче, сборка мусора, проверка на выход за границы массива. Становятся значительно дешевле обращения к полям и вызов методов.

То есть код ARM'а на x86 будет байткодом и наоборот? :)

Думаю да. И для него даже есть интерпретатор - qemu-system-arm

Нет. Он для других целей нужен.

Если первое немного спорно, то второе истинно.

Что мне надо передать JVM для этого?

JVM это не умеет, но, тем не меннее, это легко: пропатчи JVM и склей jvm с *.jar. Получишь автономный бинарь.

py2exe, перелогиньтесь пожалуйста :D

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

Почему языки, компилируемые в байткод, не компилируют в нативные команды?

Кто сказал?

py2exe, перелогиньтесь пожалуйста :D

py2exe не является JIT-компилятором, но ты верно понял суть :)

Да хоть там 10 раз JIT, если я скомпилирую зараннее 1 раз и буду запускать потом полученный бинарник, работать он будет быстрее, чем если байткод будет обрабатываться интерпретатором.

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

Тащемта компилятор Ocaml'а может компилировать как в байт-код так и в нативный, но с потерей мультиплатформенности, as you like. Правда он совсем не интерпретируемый, и типизация статическая.

Портабельность. И он таки часто компилируется в нативный - man JIT.

~ $ man JIT
Нет справочной страницы для JIT

http://ru.wikipedia.org/wiki/JIT

Почему языки, компилируемые в байткод, не компилируют в нативные команды?

Байткод нужен чтобы:
1.Откомпилированная программа запускалась на любой платформе, где есть интерпретатор
2.Не предоставлять для этого исходный код.

Я знаю, что такое JIT =) но мана такого нет. так зачем просить ввести такую команду тех, кто задаёт такой вопрос?..

1.Откомпилированная программа запускалась на любой платформе, где есть интерпретатор

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

Вопрос про то, почему нет возможности компильнуть в нативный код?

Потому что для этого нужны исходники. Чтобы их не предоставлять, компиляем в байткод и интерпретируем уже его (ну или компиляем байткод в нативный код JITом).

Так в том и вопрос, почему байткод в нативный компиляется JIT, а не один раз зараннее.

И да, проприетарщина ненужна.

почему байткод в нативный компиляется JIT, а не один раз зараннее

Если бы программы распространялись в форме исходного кода, то можно было бы компилить их в нативный код на стороне клиента (хотя тут есть свои моменты).

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