LINUX.ORG.RU
Форум — Development  

host-independent translators (in VM's byte-code)

 , ,


0

2

Пробовал ли кто-то решить проблему кросскомпиляции - созданием трансляторов в байт-коде какой-либо универсальной виртуальной машины (VM)?

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

Ответ на: комментарий от wandrien

В моей жизни пересечений не было. Вероятнее пересекусь с коболом чем с дотнетом :D А так да, тут можно просто перечислить языки с VM на борту изкоропки. Хотя ТС наверное имеет в виду чтобы просто вместо ассемблема у всех, всё шло в байткод, который потом на целевой машине уже и транслировать в бинарь обычный или исполнять в вм как есть.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

ТС так сформулировал, что вообще непонятно, чего ему надо)

Но раз уж тема про компиляторы, выскажу своё соображение. Меня всегда бесило, что gcc нужно собирать заново под каждую целевую платформу. Там разделение на фронт и бэк для красоты что ли?

Почему я не могу за один раз собрать компилятор сразу на 3, 4, 5 платформ?

Хочу tcc допилить до такого компилятора. Чтобы все бэки были сразу вкомпилированы в один бинарь. Начинал работу в этом направлении в прошлом месяце.

wandrien ★★
()
Ответ на: комментарий от wandrien

Почему я не могу за один раз собрать компилятор сразу на 3, 4, 5 платформ?

zig cc так может:

andy@ark ~/tmp> zig cc -o hello.exe hello.c -target x86_64-windows-gnu
andy@ark ~/tmp> wine64 hello.exe
Hello, World!
andy@ark ~/tmp> zig cc -o hello hello.c -target mipsel-linux-musl
andy@ark ~/tmp> qemu-mipsel ./hello
Hello, World!
andy@ark ~/tmp> zig cc -o hello hello.c -target aarch64-linux-gnu
andy@ark ~/tmp> qemu-aarch64 -L ~/Downloads/glibc/multi-2.31/install/glibcs/aarch64-linux-gnu ./hello
Hello, World!

https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html

No ★
()
Ответ на: комментарий от wandrien

dotNET

В неполной мере идеи о трансляторах академика СО АН СССР Ершова Андрея Петровича реализованы в .NET, согласен. Но от этого отечественная школа программирования (от дот-нэт) практически ничего не получила, кроме трудоустройства пары олимпиадников в Микрософт в начале 2000-х.

Mirage1_ ★
() автор топика

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

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

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

alysnix ★★★
()

сугубо теоретически, связка

[текстЪ программы] -> [промежуточный код высокого уровня] -> [ исполнение с JIT ]

при исполнении на конечном железе будет сопоставимо с выполнением заранее скомпилённого нативного кода. И даже иногда его обгонять. Но при условии что промежуточный код это не байт-код VM, а именно почти язык программирования, просто закодирован в быстро-машиночитаемый формат с плюшками облегчающими генерацию JIT и оптимизацию.

классические VM (java .net) имеют серьёзный недостаток - для эффективности они должны быть близки к реальному железу (к которому ? их много разных), к тому байт-код это низкий уровень - его на лету не сильно пооптимизируешь.

PS/ но только практического смысла очевидно что нет - «универсальные ЯП» на все случаи жизни плавно уходят, конечный софт состоит из частей на разных языках хорошо заточенных под свою плоскость. Образно gui отдельно, числодробилко отдельно, IO отдельно.

MKuznetsov ★★★★★
()
Development