3

Я знаю, что язык ассемблера обычно не является межплатформенным. И даже с такими вещами, как NASM, вам по-прежнему нужен другой код для разных архитектур и платформ, которые имеют разные временные ряды и реализации таких вещей, как прерывания. Но если кто-то хочет программировать на ассемблере, потому что им это нравится, существует ли какая-либо реализация кросс-платформенного языка ассемблерной архитектуры?Язык кросс-платформенной архитектуры/архитектуры Язык

Edit:

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

ответ

7

Я думаю, что MMIX Дональда Кнута вас интересует. Кнут пишет программы в своем The Art of Computer Programming book на этом компьютере/ассемблере. На сегодняшний день ЦП не поддерживает его напрямую. Есть только эмуляторы. О, кто-то сделал FPGA, который может его запустить. Но это все.

1

№ Язык C может быть тем, что ближе всего к кросс-платформенному языку более низкого уровня.

+0

bytecodes намного ближе, чем C, C - язык высокого уровня. на основе стека, в частности (java), а некоторые процессоры на основе стека (zpu) ближе к общему asm. –

+2

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

+2

OP запросил программирование на языке ассемблера кросс-системы. Никто не пишет программы в байтовых кодах. – uselpa

1

Как вы сказали, сборка не является межплатформенной (вы можете удалить «типичную» часть). У меня мало информации, но похоже, что C-- может заинтересовать вас как «портативный язык ассемблера», как описано на их странице.

+0

И вообще, кто говорил о C здесь? Посмотрите еще ближе. Я сказал ** C - **. Поскольку, похоже, вы даже не тратили свое время, чтобы нажать ссылку, я приведу C-домашнюю страницу: «Вы были бы намного счастливее с одним ** переносным языком ассемблера **» – m0skit0

+0

Я согласен с вами, но все же ваш комментарий снова оффтопик. – m0skit0

+0

Я уже связан с главной страницей, иди туда, если хочешь получить более подробную информацию. Я не собираюсь повторять сказанное. И вообще, это обсуждение не является конструктивным для самого вопроса. – m0skit0

2

Следующая ссылка представляется релевантной. Why is programming in bytecode not as popular or prevalent as programming in assembly?

Особенно ответ Икегами:

Искусственные языки сборки предназначены для обслуживания потребности языка, для которого они предназначены, и имеют очень близкие отношения с ними, а не аппаратного обеспечения. Существует не так много, как можно сделать с ними, что не может быть так же легко достигнуто на языке более высокого уровня. <

1

EDIT:

Ассемблер обычно имеет один к одному отношения судно с машинным кодом, или набор команд для этого процессора/системы. Системы по-разному, потому что они имеют разные наборы инструкций. Таким образом, по определению у вас не может быть набора кросс-системных команд, поэтому нет языка ассемблерной перекрестной системы и его все еще называют языком ассемблера.

Ближайшие, которые вы найдете, это виртуальные наборы команд, если вы будете близки к уровню машины, поскольку у них есть свойства, которые являются общими для многих наборов инструкций, отношения один к одному или от одного до нескольких с машинным кодом, но не особенно для одной машины. Например, байт-код Java, байт-код python, p-код pascal и т. Д. Это машины на основе стека, большинство процессоров имеют стеки или могут легко реализовать машину на основе стека, используя нагрузки и магазины. Машины на основе стека используют несколько регистров, еще один способ получить перекрестную систему, а не слишком тяжело применять на различных наборах инструкций. Основанный на стеке также лежит в основе бэкэнда small-c, поэтому он так легко переносится из одной системы в другую. История повторяется, эти четыре языка не являются последними языками, которые будут сводиться к машине на основе стека, это произойдет снова и снова.

Если вам нравится сборка, вы можете найти java или python бэкэнды интересными и, возможно, забавными. У них, вероятно, нет ассемблера только машинный код, поэтому вам, вероятно, потребуется написать собственный ассемблер. Лично я бы начал с дизассемблера, чтобы почувствовать язык, затем пойти другим путем и написать байт-код или создать ассемблер. В равной степени удовольствие может быть связано с реализацией виртуальной машины для конкретного процессора.

Ваши комментарии о симпатии ассемблера, а затем использование слова NASM подразумевает x86.x86 - несколько неприятный ассемблерный язык, если вы не испытывали других, есть еще несколько красивых языков ассемблера. Вы должны попробовать их вместо того, чтобы искать один размер, подходящий для всех (который вы на самом деле не найдете).

+0

Это скорее комментарий, чем ответ, так как вы не отвечаете на вопрос: «Существует ли какая-либо реализация кросс-платформенного языка ассемблерной архитектуры?» * И я не знаю, откуда у вас появилась идея, что он не нравится сборка ... – m0skit0

+0

Я не собираюсь повторять то, что уже говорили вам другие. Посмотрите на комментарии к ответу от uselpa. – m0skit0

+0

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

3

LLVM - это язык низкого уровня (целью которого является бэкэнд компилятора), который очень похож на AT & T сборка, если не на 10 раз хуже. Вот пример:

define i32 @add_sub(i32 %x, i32 %y, i32 %z) { 
entry: 
    %tmp = add i32 %x, %y 
    %tmp2 = sub i32 %tmp, %z 
    ret i32 %tmp2 
} 

Это примерно equilavent со следующей рукописной x86 сборки:

; Body 
mov eax, edi 
add eax, esi 
sub eax, edx 
ret 

LLVM ооо 3.3 генерирует следующий код (с отступом по-разному для удобства чтения):

.file "add_sub.ll" 
    .text 
    .globl add_sub 
    .align 16, 0x90 
    .type add_sub,@function 
add_sub:      # @add_sub 
    .cfi_startproc 
# BB#0:       # %entry 
    lea EAX, DWORD PTR [RDI + RSI] 
    sub EAX, EDX 
    ret 
.Ltmp0: 
    .size add_sub, .Ltmp0-add_sub 
    .cfi_endproc 


    .section ".note.GNU-stack","",@progbits 

Соответствующий код:

lea EAX, DWORD PTR [RDI + RSI] 
sub EAX, EDX 
ret 

Как вы можете видеть, LLVM имеет очень мощный оптимизатор. Скорее всего, это самое близкое, что вы получите.