Итак, мы изучаем архитектуру MIPS в школе, и мы внедряем архитектуру MIPS32. Я думал, что буду использовать GNU cross-binutils как ассемблер, но я получаю странный вывод при работе с инструкциями jal, j и jr. Кажется, что ассемблер вставляет инструкции в неправильные места. Я понятия не имею, почему это происходит, и я сомневаюсь, что ассемблер MIPS был бы сломан, поэтому я предполагаю, что это должно произойти.Weird MIPS ассемблер с инструкцией о прыжке (и ссылке)
Вот мой манекен файл сборки:
.section .text
.globl __start
__start:
addi $a0, $0, 100
addi $a1, $0, 200
jal test
test:
add $v0, $a0, $a1
jr $ra
Однако, когда я разборку я получаю этот выход:
Disassembly of section .text:
00000000 <__start>:
0: 20040064 addi a0,zero,100
4: 0c000003 jal c <test> <--- Why is jal coming before addi?
8: 200500c8 addi a1,zero,200
0000000c <test>:
c: 03e00008 jr ra <--- Why is jr coming before add?
10: 00851020 add v0,a0,a1
...
Является ли это какой-то архитектурный причуда? Если да, то в чем причина этого?
EDIT: испытана добавлением некоторого NOP это только для щеколды ...
.section .text
.globl __start
__start:
addi $a0, $0, 100
addi $a1, $0, 200
nop
jal test
test:
add $v0, $a0, $a1
nop
jr $ra
, и это дает мне то, что кажется несколько правильно.
Disassembly of section .text:
00000000 <__start>:
0: 20040064 addi a0,zero,100
4: 200500c8 addi a1,zero,200
8: 0c000004 jal 10 <test>
c: 00000000 nop
00000010 <test>:
10: 00851020 add v0,a0,a1
14: 03e00008 jr ra
18: 00000000 nop
1c: 00000000 nop
Почему jal и j заменяют места последней инструкцией?
Похоже на проблемы с обратным порядком байтов внутри компилятора (или дизассемблер), только на командном слое вместо байтов слоя ... странно ... – schnaader