MIPS32->MIPS16E

As a 32-bit Instruction Set Architecture, the code density of MIPS32 is not as high as that of MIPS16E. Our practice has shown that if a program is built with MIPS16E instead of MIPS32, the code size will be two third of its original length.

There were some concernings before the whole system is built with MIPS16E:

  • Is all functions could be implemented by MIPS16E instructions?
    Yes, there are some limitations of MIPS16E instructions:
    • CP0 registers couldn't be accessed by MIPS16E instructions.
    • The instruction "sync" is not available in MIPS16E mode.
    • Interrupt/Exception vectors must be MIPS32 code.
  • Is the performance of MIPS15E as good as that of MIPS32?
    • No material shows that the performance of MIPS16E is poor than MIPS32.
    • A document from MIPS indicates that the actual performance of MIPS16E is even better than MIPS32, for the cache could accommodate more 16bit instructions than 32-bits instructions.

We have to make some modules be build with MIPS32 ISA for the following reason:

  • the MIPS16E instruction is not full-functional.
  • There are some code is written with MIPS32 assemble.

Anyway, most code of Rigel is architecture independent and could be build with MIPS16E.

While compiling a source(C,CPP) file, MIPS16E or MIPS32 could be specified as gcc's option -mips32 or -mips16. In-line asm code couldn't be build with incorrect gcc options. For Rigel there are only MIPS32 in-line asm statements(We are not familiar with MIPS16 instructions), it means some files coudn't be compiled with -mips16 option. A Macro, __MIPS16E__, is defined for avoiding MIPS32 asm code from a .h file which is included by the c files that compiled with MIPS16E ISA.

The options "-mips16 _D__MIPS16E__" are added to the global cflag(src/ecos-2.0-antares/packages/hal/mips/mips324ke/current/cdl/hal_mips_mips32_4ke.cdl).

For the modules that couldn't be compiled with MIPS16E, these options are hidden by defining cdl_option CYGPKG_XXXXXXXX_CFLAGS_REMOVE in their cdl files.

modulereason
driver_adecin-line asm code of MIPS32
driver_front_panelin-line asm code of MIPS32
halArchitecture dependent code. Accessing CP0, MIPS32 asm source.

There are some issues when the whole system is built:

  • Function-like macros written in MIPS32 asm code.

There are some funcion-like marcros defined in .h file and be used as functions, such as HAL_ENABLE_INTERRUPT(), they are written in MIPS32 asm code. They are also called in the .c file that is built with MIPS16 ISA. With the help of the macro __MIPS16E__, the macros will will be re-defined as real functions:

#ifndef __MIPS16E__

#define HAL_ENABLE_INTERRUPTS()                 /
{                                               /
	asm volatile (                              /
			"mfc0   $8,$12; nop;"                   /
			"or     $8,$8,1;"                       /
			"mtc0   $8,$12;"                        /
			"nop; nop; nop;"                        /
			:                                       /
			:                                       /
			: "$8"                                  /
		     );                                      /
}
         ....

#else //if __MIPS16E__ is defined:

void hal_enable_interrupts(void);
...
#define HAL_ENABLE_INTERRUPTS()                 hal_enable_interrupts()

#endif

When such functions are actually defined, the code is very interesting:

src/ecos-2.0-antares/packages/hal/mips/mips324ke/current/src/var_misc.c:

__ExternC void hal_enable_interrupts(void)
{
    HAL_ENABLE_INTERRUPTS();
}

Sure var_misc.c must be compiled with MIPS32, and __MIPS16E__ undefined.

  • Switching between MIPS32 and MIPS16E

MIPS CPU can jump between the code of MIPS32 and MIPS16E directly, without any special mode switching operation. But not all of the jumpping /branch instructions could be used for mode switching. Fortunately in most case the switching between MIPS32 and MIPS16E is not a problem, except that when sibling calls is optimizes by gcc, a illegal instruction will be used for jumping from MIPS32 code to MIPS16E code.
Disable the optimization of sibling call for MIPS32 code with gcc option:

-fno-optimize-sibling-calls

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值