免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
12
最近访问板块 发新帖
楼主: albcamus
打印 上一主题 下一主题

x86-64汇编问题请教 [复制链接]

论坛徽章:
0
11 [报告]
发表于 2008-07-16 23:27 |只看该作者
原帖由 mik 于 2008-7-16 23:10 发表


偶最善此道了。

你提到的问题并不复杂。 实际上只是汇编语言层面的语法而已。

1、从本质上讲与你所说的 -1 完全无关,也没有什么 0x7fffffff 的制约。

2、出现 addq $0xffffffff, %rax  ...

牛啊!
也就是说编译不过完全是因为汇编器限制了?
但我还是没看懂为啥要有这样的限制。

论坛徽章:
0
12 [报告]
发表于 2008-07-16 23:32 |只看该作者
原帖由 zx_wing 于 2008-7-16 23:27 发表

牛啊!
也就是说编译不过完全是因为汇编器限制了?
但我还是没看懂为啥要有这样的限制。

从汇编语法上来讲:x86 & x64 的指令格式绝大部分要求:源操作数与目的操作数的大小要一致
其实,C语言不也会这样吗,语义与语法偶尔也很混乱

论坛徽章:
0
13 [报告]
发表于 2008-07-16 23:36 |只看该作者
原帖由 mik 于 2008-7-16 23:32 发表

从汇编语法上来讲:x86 & x64 的指令格式绝大部分要求:源操作数与目的操作数的大小要一致
其实,C语言不也会这样吗,语义与语法偶尔也很混乱

那不对啊,目的操作数是rax,为啥小于0x80000000的可以呢,它们是32bit的源操作数啊

[ 本帖最后由 zx_wing 于 2008-7-16 23:39 编辑 ]

论坛徽章:
0
14 [报告]
发表于 2008-07-16 23:56 |只看该作者
原帖由 zx_wing 于 2008-7-16 23:36 发表

那不对啊,目的操作数是rax,为啥小于0x80000000的可以呢,它们是32bit的源操作数啊

这只能说是语义上的问题了

当 add rax, 0x7FFFFFFF  的时候: 立即数是真正的 32 位的,不会被认为是扩展到 64位的
此时,它的机器直接对应为: 49 05 FF FF FF 7F

当 add rax, 0xFFFFFFFF 的时候: 立即数被扩展到 64位 0xFFFFFFFFFFFFFFF 从语法层面来讲,
它必须出现 add rax, 0xFFFFFFFFFFFFFFFF 这种形式。

反正这就是汇编语义语法上的问题,汇编器实现上的问题。我们只能接受了,除非你自己实现汇编器

论坛徽章:
0
15 [报告]
发表于 2008-07-17 00:50 |只看该作者

赫赫

更正下
实际上不止-64有这样的问题,32位也有这样的问题,
比如mips,下面指令
lw $2, 0x8000($0)
本意要读取外部0x8000地址。
lw 指令要求立即数16位,第16位为符号位,扩展成32位的表示范围为0x0000_0000 ~ 0x0000_7fff ;0xffff_8000 ~ 0xffff_ffff.可见要访问0x8000并不在这个范围内,结果变成了0xffff8000.当然,如果为正数,就不会有问题。

所以这里就有问题了。编译器如何处理这种情况,这就要看编译器怎么处理了!就是mik说的。

回到x86-64,也会出现类似问题,处理方法相同。

[ 本帖最后由 fineamy 于 2008-7-17 08:57 编辑 ]

论坛徽章:
0
16 [报告]
发表于 2008-07-17 10:32 |只看该作者
这应该是符号扩展的问题吧,在 64 位运算中,32 位立即数被解释为有符号数,addq $0xffffffff, %rax 这是个有符号数应该使用符号扩展
,但是有个 隐式零扩展的问题这个数会被搞成0x00000000ffffffff,因此它是非法的。addq 0x0-0x7fffffff,%rax 所以是有效指令。

论坛徽章:
3
2015年迎新春徽章
日期:2015-03-04 09:56:11数据库技术版块每日发帖之星
日期:2016-08-03 06:20:00数据库技术版块每日发帖之星
日期:2016-08-04 06:20:00
17 [报告]
发表于 2008-07-17 10:56 |只看该作者
呵呵,我就奇怪呢,64位CPU怎么会有这种无理的要求
看来只能嵌机器语言了...........

论坛徽章:
0
18 [报告]
发表于 2008-07-17 11:36 |只看该作者
原帖由 mik 于 2008-7-16 23:10 发表


偶最善此道了。

你提到的问题并不复杂。 实际上只是汇编语言层面的语法而已。

1、从本质上讲与你所说的 -1 完全无关,也没有什么 0x7fffffff 的制约。

2、出现 addq $0xffffffff, %rax  ...



多谢多谢,昨天我们讨论,就知道得问你才行

我差点就发在comp.lang.asm.x86上了^_^


PS, 能否再帮小弟确认一个观点: Unix下的REX并不需要程序员来关心(而只是as作者关心)?  感觉AT&T风格的汇编一直是用addq的“q”、“l”这样的后缀就行了, 至于如何设置指令码种的REX, 程序员就不用关心了吧?

论坛徽章:
0
19 [报告]
发表于 2008-07-19 22:19 |只看该作者
原帖由 albcamus 于 2008-7-17 11:36 发表

PS, 能否再帮小弟确认一个观点: Unix下的REX并不需要程序员来关心(而只是as作者关心)?  感觉AT&T风格的汇编一直是用addq的“q”、“l”这样的后缀就行了, 至于如何设置指令码种的REX, 程序员就不用关心了吧?...


对呀。
汇编程序员的工作只是给出指令就行了。是怎样翻译为机器编码就是 assembler 的工作了。
x86 机器的大部分通用指令都可以有2种以下的译法。
比如最简单的: mov eax, ebx 就至少有两种机器编码。:wink:

论坛徽章:
0
20 [报告]
发表于 2008-11-24 22:46 |只看该作者
开始还纳闷写汇编的时候怎么用REX呢,后来才明白写汇编器才用得到REX,看了这帖子才明白mik版主说的a64主要的优势是语法比较好。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP