LINUX.ORG.RU

История изменений

Исправление uin, (текущая версия) :

фундаментально проблему не решает

«Фундаментальную проблемму» необходимости портирования ПО не решает ни одна архитектура. Все платформы обрастают мясом постепенно, еще каких то 10 лет назад под арм небыло нихрена, сейчас же aarch это вторая по поддерживаемости платформа (усилиями крупных компаний прежде всего) после ia32. В какой проект не загляни там поддержка интеловских расширений где через интринсики а где и на ассемблере, интел сам к этому шел 20 лет.

Потому что Rust решил выбрать llvm как бэкэнд, Go решили сделать свой.

И что? У LLVM есть входной формат данных, поддержи этот формат в своем компиляторе и будет у тебя раст. Go помоему на gcc базируется, поддержи и формат gcc.

С интерпретаторами та же фигня

Интерпритаторы (быстрые) пишут на ассемблере, там на нем реализовывают те функции через которые виртуальная машина целевого языка реализует себя. Все это надо писать под каждый процессор отдельно, нельзя просто взять код арм или x86 и поправить на rve64 например.

В случае с эльбрусом с его особенностями работы с памятью, ему еще придется писать свой сборщик мусора (или не писать, если он не обязателен в тойили иной среде), зато вместо местячкового jit-а сомнительного качества можно будет вызывать родной качественный компилятор. В большинстве языков (даже том же самом luajit) jit компилятор опционален. Чуваки которую джаву портировали вместо имеющихся в джаве jit -ов (там их два помоему) взяли сперва какой то проект на llvm и оно работало.

Исходная версия uin, :

фундаментально проблему не решает

«Фундаментальную проблемму» необходимости портирования ПО не решает ни одна архитектура. Все платформы обрастают мясом постепенно, еще каких то 10 лет назад под арм небыло нихрена, сейчас же aarch это вторая по поддерживаемости платформа (усилиями крупных компаний прежде всего) после ia32. В какой проект не загляни там поддержка интеловских расширений где через интринсики а где и на ассемблере, интел сам к этому шел 20 лет.

Потому что Rust решил выбрать llvm как бэкэнд, Go решили сделать свой.

И что? У LLVM есть входной формат данных, поддержи этот формат в своем компиляторе и будет у тебя раст. Go помоему на gcc базируется, поддержи и формат gcc.

С интерпретаторами та же фигня

Интерпритаторы (быстрые) пишут на ассемблере, там на нем реализовывают те функции через которые виртуальная машина целевого языка реализует себя. Все это надо писать под каждый процессор отдельно, нельзя просто взять код арм или x86 и поправить на rve64 например.

В случае с эльбрусом с его особенностями работы с памятью, ему еще придется писать свой сборщик мусора (или не писать, если он не обязателен в тойили иной среде), зато вместо местячкового jit-а сомнительного качества можно будет вызывать родной качественный компилятор. В большинстве языков (даже том же самом luajit) jit компилятор опционален. Чуваки которую джаву портировали вместо имеющихся в джаве jit -ов (там их два помоему) взяли сперва какой то проект на llvm и оно работало.

тота памяти можно 32гб DDR3 напихать. Да вот олько не поддерживает он ни то что sse4,1/4,2 но и даже ssse3, не говоря уже о более новых. Говорят киберпанки всякие компилируют уже с расчетом на то что в каждом процессоре давно есть sse4, и это только начало