GCC中microMIPS、-minterlink-compressed选项及跨ISA调用问题咨询

Let’s tackle each of your questions clearly—these ISA mode and linking options are critical for optimizing embedded RTOS binaries without breaking cross-unit calls, so it’s great you’re digging into the details.

1. Is your understanding of microMIPS correct, and does it have other advantages? #

Your core takeaway is spot-on: the -mmicromips option tells GCC to generate compressed 16-bit microMIPS instructions (plus some 32-bit ones where needed) to slash the size of your binary image—this is its primary value for memory-constrained embedded devices.

Beyond size reduction, microMIPS offers a few practical perks:

• Better cache efficiency: Compact instructions let more code fit into the tiny L1 caches common in embedded MIPS chips. This cuts down on cache misses, which can boost real-world execution speed even if individual microMIPS instructions take a cycle or two longer than their 32-bit MIPS equivalents.
• Lower power draw: Fewer bytes fetched from flash/ROM means less bus activity, which translates to reduced power consumption—huge for battery-powered embedded systems.
• Backward compatibility: microMIPS is a superset of MIPS16e and works with most standard MIPS instructions, so you don’t have to rewrite existing code to use it (just recompile with the flag).

2. What’s the purpose of the -minterlink-compressed option? #

This linker option directly solves the cross-ISA-mode calling problem you hit later. When you mix compiled units built with -mmicromips (16-bit compressed instructions) and regular MIPS (32-bit instructions), direct jumps between them fail because the CPU can’t switch ISA modes mid-execution with a standard branch.

-minterlink-compressed tells the linker to automatically generate tiny jump stubs (adapter code snippets) that handle the ISA mode switch. These stubs sit between the caller and callee: when a non-microMIPS function calls a microMIPS function (or vice versa), the stub switches the CPU’s mode before executing the target function, then switches back on return. Best of all, these stubs are compact, so they don’t bloat your binary significantly.

3. Fixing the "unsupported jump between ISA modes" error #

Let’s break down both solutions you mentioned:

Solution 1: Enable -minterlink-compressed (this is absolutely applicable) #

This is the cleanest, most scalable fix. Just add -minterlink-compressed to your linker flags (not just compiler flags)—the linker will handle all cross-mode call stubs automatically, no code changes required. This works for every cross-unit call, so you won’t have to modify individual function calls manually.

Solution 2: Implement forced indirect jumps in C code #

If you can’t use the linker option (e.g., if your linker lacks support), you can force an indirect jump via a function pointer, which bypasses the direct branch’s ISA mode check. Here’s a concrete example:

// Declare your microMIPS function (from another compilation unit)
extern void my_micromips_function(void);

// Create a function pointer pointing to the microMIPS function
void (*func_ptr)(void) = my_micromips_function;

// Call the function via the pointer (this forces an indirect jump)
func_ptr();

Under the hood, MIPS architectures use the least significant bit (LSB) of a function address to indicate ISA mode: 1 means microMIPS, 0 means standard MIPS. When you assign the function to a pointer, the LSB is preserved, and the indirect jump uses this bit to automatically switch the CPU’s mode to match the target function.

You can also explicitly mark functions with compiler attributes to enforce their ISA mode:

// Force a function to be compiled as microMIPS
__attribute__((micromips)) void my_micromips_function(void) {
    // Code here
}

// Force a function to NOT use microMIPS
__attribute__((nomicromips)) void standard_mips_function(void) {
    // Code here
}

内容的提问来源于stack exchange，提问作者sagivd