7

Following this question: Weird MIPS assembler behavior with jump (and link) instruction I have a working GNU assembly toolchain for my single cycle MIPS project (no branch delay slot!). I would really prefer to write in C though. The code itself generated from the compiler does run, but I have to manually edit the assembly source every time since GCC for some reason likes to automatically reorder the branching instructions itself. I don't want to hack this with a script to figure out when to reorder the branches back again.

Is there a possible way to circumvent this? GCC generates code like this for some reason:

.set noreorder
...
jr $ra <-- GCC reordered for me!
addi $v0, $v0, 10 <--
...
.set reorder

where I really want to feed the assembler something like this:

.set noreorder
addi $v0, $v0, 10
jr $ra
Community
  • 1
  • 1
Maister
  • 4,978
  • 1
  • 31
  • 34

2 Answers2

10

pass the -mips1 and -fno-delayed-branch flags to gcc.

Kaalras
  • 1,073
  • 10
  • 13
sergio johann filho
  • 101
  • 1
  • 2
  • 1
    And then just remove the NOPs. gcc still compiles for the real MIPS ISA, that just disables taking advantage. https://godbolt.org/g/XmxVMu. Handy if you want code for SPIM or MARS with their default of simulating a MIPS with no branch delay. – Peter Cordes Mar 27 '18 at 17:32
  • Related: [Is there a way to use gcc to convert C to MIPS?](https://stackoverflow.com/a/63386888) / [Tweak mips-gcc output to work with MARS](https://stackoverflow.com/q/13052444) – Peter Cordes Nov 02 '22 at 19:48
3

I don't think it's possible to turn it off since delay slots are present in all MIPS variants. I think it's much better if you implement delay slots in your emulator. This will also make it closer to real hardware.
Barring that, you can probably patch gcc to stop trying to fill the delay slots.

Igor Skochinsky
  • 24,629
  • 2
  • 72
  • 109
  • It's implemented in hardware, so will be a bit messy to restructure lots of the design for that. I guess I'll have to write a small script for this, then. – Maister Oct 28 '10 at 18:09