Итак, мы изучаем архитектуру MIPS в школе и реализуем архитектуру MIPS32. Я думал, что буду использовать GNU cross-binutils в качестве ассемблера, но я получаю странный результат, когда имею дело с инструкции jal, j и jr. Ассемблер, кажется, вставляет инструкции не в те места. Я понятия не имею, почему это происходит, и я сомневаюсь, что ассемблер 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
...
Это какая-то архитектурная причуда? Если да, то каково обоснование этого?
РЕДАКТИРОВАТЬ: Протестировано добавление некоторых 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 меняются местами с последней инструкцией?