байт код

[mirk]

Насколько я помню, еще в довольно древние времена Н.Вирт в паскаль ввел такое понятие как байт-код

Потом эта "фича" появилась у явы
Сейчас мы наблюдаем подобное у .NET
Также последний перл тоже начал уметь компилировать в байт-код, пхп имеет что-то подобное (только с якобы шифрованием)

Я так понимаю у каждого компилятора (или интерпритатора) свое понятие о байт-коде. Собственно хотелось узнать какие особености, недостасти и плюсы у каждого. Ведь для современного языка и байт-код думаю пригодится

[alexs]

фактически это ещё один тип поддерживаемого процессора. Причём интерпретаторов P-кода может быть множество (тот же Net, J и т.д.)

[ev]

кстати, есть компилятор оберона в байт-код ява-машины

[trifon]

Ocaml имеет просто интерпретатор, интерпретатор байткода, компилятор.
Разница как в скорости так и в размере бинарника весьма существенная. Интерпретатор текста самый медленный и бинарника естественно не имеет, байткод имеет раза в полтора меньший размер файла чем у скомпилированного кода, однако запускается через байткод-интерпретатор и существенно медленней.
Мне кажется о байткоде лучше на википедии читать, на подобные вопросы там всегда есть страничка на русском

[trifon]

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

[e-moe]

Кто-то тут о скорости говорил... По-моему в .NET с эти не плохо придумали: при запуске в первый раз байт код компилируется в нативный код именно для текущего процессора на котором он запущен + все оптимизации. При следующем запуске будет уже использоваться заранее скомпилированный и сохраненный нативный код.

[stanilar]

IMHO

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

В настоящее время байт-код - это способ не дать программистам свободно переносить свои решения с одной платформы на другую. Если верить ohloh'у количество С - кода бьет рекорды.

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

Это повод упрекнуть Microsoft в растранжировании энергоресурсов стран. Сразу скомпилировать в нативный не так сложно, даже для нескольких платформ windows.

[pda]

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

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

[*Rik*]

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

Как раз наоборот, Java не только жива, но и способствовала появлению C# и в настоящее время эти технологии очень востребованы.

В настоящее время байт-код - это способ не дать программистам свободно переносить свои решения с одной платформы на другую. Если верить ohloh'у количество С - кода бьет рекорды.

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

[скалогрыз]

Я так понимаю у каждого компилятора (или интерпритатора) свое понятие о байт-коде. Собственно хотелось узнать какие особености, недостасти и плюсы у каждого. Ведь для современного языка и байт-код думаю пригодится

Ориентируйся на лидера в экономическом плане. Т.е. выбор между Гуглом (с его переносом java-код в dalvick) и Майкросов с его CLI.

ну и как придут новые байт-коды и новые лидеры, придёться подстраиваться под них. Но после первой реализации это делать будет намного проще.

Ну а технические параметры не так уж важны.

[*Rik*]

Насколько я помню, еще в довольно древние времена Н.Вирт в паскаль ввел такое понятие как байт-код

Да, всё верно, само понятие бай код исходит из того, что им кодируются инструкции вымышленного RISC процессора, количество простых команд которого ограничено и 1 команда умещается в 1 байт (т.о. всего команд не более 255), отсюда и название. Атрибуты самой команды могут быть довольно длинные и указывать на регистры или области памяти, но сама команда всегда не более 1 байта.

Я так понимаю у каждого компилятора (или интерпритатора) свое понятие о байт-коде.

Никаких правил нет, если есть желание можете придумать и реализовавть любой набор инструкций, какой хотите.

[stanilar]

Как раз наоборот, Java не только жива, но и способствовала появлению C# и в настоящее время эти технологии очень востребованы.

Именно сейчас они и стали очень востребованы. Что говорит о том, что байт код имеет очень опосредованное отношение к понятию "разные платформы".

Кстати, ни С#, ни JAVA еще не отменили Си, частью которого и является паскаль. В этом связи можно провести очень интересное наблюдение - FPC может компилировать под разные платформы, а вот C# и Dalvik не очень (Я еще не видел полноценных продуктов C# на Androide, и продуктов под Dalwik на винде).

[скалогрыз]

Кстати, ни С#, ни JAVA еще не отменили Си, частью которого и является паскаль

классная фраза для начала срача C vs Pascal

[pda]

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

Вот это вы зря кстати так. Приличная часть софта написана на C++, у которого очень медленная скорость компиляции. Крупные проекты вынуждены держать фермы компиляции (для сборки дистрибутивов или windows) и даже там ряд тяжёлых пакетов, вроде libreoffice может часами собираться.

Но время не единственный фактор. Для кросс сборки потребуется иметь тулчейны для всех платформ, причём в принудительном порядке и это всё равно не гарантирует работы программы на платформе, отличной от платформы разработчика, где он тестировал. Так стоит ли оно... Apple в период перехода с PowerPC на x86_64 кнутом заставляла свои универсальные файлы делать. В Linux, когда предложили идею fatelf (несколько платформ, склеенных в одном имполняемом файле) тоже было без энтузиазма воспринято...

[скалогрыз]

Apple в период перехода с PowerPC на x86_64 кнутом заставляла свои универсальные файлы делать.

Не совсем так, с PowerPC переходили на i386 либо x86_64 (по вкусу и желанию).

Кнутом универсальные файлы не заставляли делать. Наоборот, давали возможность стряпать универсальные бинарики. (что кстати, странно, учитывая, что OSX использует Бандлы. Могли бы и на уровне bundl-а разрулить два разных исполняемых фалов).
Можно сделать бинарик, поддерживающий все 4 архитектуры, PPC, PPC64, i386, x86_64.

В то время стали появлятся програмки, с требованием OSX 10.4 Intel-only.

Ну а дальше, OSX как и винды, позволяет запускать 32-битные приложения без проблем на 64-битной ОСи или процессоре. Кстати сам OSX поставлялся сразу 32/64 и подстраивался под установленное железо... Что в случае с маками, не так уж и сложно.