【BUAA_CO_LAB】Pre_MIPS指令集_MARS帮助文档整理_伪指令

MARS帮助文档整理_伪指令

指令名称	功能概述
.align*	在指定的字节边界上对齐下一个数据项（0=byte，1=half，2=word，3=double），也即指令后的下一个字段将对齐为 2 的 n 次幂的倍数，其中 n 是 .align值
.ascii	将字符串存储在数据段中但是不添加终止符’\0’（之后再添加会直接跟在字符串后）
.asciiz	将字符串存储在数据段中但是添加终止符’\0’
byte	将后面列出的值存储为8bit数据（一个字节）
.data	后续值存储在下一个可用地址的数据段中 → [块] 用于定义程序的数据段，初始地址为address，若无address参数，初始地址为设置的默认地址。
.double	将后面列出的值存储为双精度浮点数
.macro & end_macro	中间夹一段用于进行宏定义的代码块
.eqv	用法类似c语言里的**#define**，即用第一个操作数代替第二个
.extern	将列出的标签和字节长度声明为全局数据段
.float	将后面列出的值存储为单精度浮点数
.globl	定义后面列出的标签为全局量，以便在其他文件中引用
.half	将后面列出的值存储为半字边界上的 16 bit半字
.include	插入指定文件的内容，将文件名放在引号中
.kdata	后续值存储在下一个可用地址的内核数据段中
.ktext	后续项目/指令存储在下一个可用地址的内核文本段中
.set	设置汇编器变量，当前被忽略但包含在 SPIM 兼容性中
.space	在数据段中保留后列的指定数量的字节，相当于开辟出一段空间
.text	后续项目/指令存储在下一个可用地址的文本段中
.word	将后面列出的值存储为一字边界上的 32 bit字

*初看时只对伪指令中的.align不太理解。后来在StackOverflow上找到一个关于.align应用的一个Example

即，我将当前所处地址的数据用unused扩展成64bit，即3对应的doubleword。

对齐对于 MIPS 处理器很重要，它只能从内存中读取地址为数据大小倍数的地址处的多字节值。目标地址必须是所访问之数据单元字节数的整数倍（也即该类型对应字节数 / 8）。比如要访问一个32位的整数，那么这个数据必须（最好）存储在以4字节（32/8=4）对齐的地方。接下来看这个例子吧。

.ASCIIZ 字段可以放在任何地方，因为一次只会读取一个字符串一个字节（1的倍数可以是随便的什么数）。所以把它放在 0x10010003 就可以了。

而.WORD 字段必须与 4 的倍数对齐。因此它不能放在 0x1001000E，即字符串之后的下一个可用位置。所以汇编器会有意移动该值并留下两个unused字节。到下一个为 4 的倍数的地址，也就是0x10010010。

.ALIGN 指令是一种覆盖默认对齐规则的方法。指令后的下一个字段将对齐为 2 的 n 次幂的倍数，其中 n 是 .ALIGN 值。在上图则对齐到 pow(2, 3) = 8 个字节。

也就是说，如果没有 .ALIGN 指令，.HALF 字段将存储在 0x10010014（half对齐到2的倍数）。这个数不是 8 的倍数，所以它被移动到 0x10010018，这样就完成成了所谓的扩展到64bit（双字）。

Alignment is important for a MIPS processor, it only likes to read multi-byte values from memory at an address that’s a multiple of the data size.

The .ASCIIZ field can be placed anywhere since a string is read one byte at a time. So putting it at 0x10010003 is fine.

The .WORD field must be aligned to a multiple of 4. So it can’t be put at 0x1001000E, the next available location after the string. The assembler intentionally shifts the value and leaves two bytes unused. To the next address that’s a multiple of 4, 0x10010010.

The .ALIGN directive is a way to override the default alignment rules. The next field after the directive will be aligned to a multiple of 2 to the power of n where n is the .ALIGN value. In your case that’s pow(2, 3) = 8 bytes.

Which is what you see happening, without the .ALIGN directive the .HALF field would be stored at 0x10010014. Not a multiple of 8 so it is moved to 0x10010018.

The example is otherwise artificial, no obvious reason to use the .ALIGN directive here since .HALF only requires an aligment to a multiple of 2 so storing it at 0x10010014 would have been fine.

——From Hans Passant