这是真正的分歧所在.
对于64bit这次大侠的确有误
大侠自己可以测试一下或查一下intel的资料或与intel的人确认一下,再做结论.
如果大侠测试出不同的结果,请告知编译工具和平台,以便客观的进行交流.
可 ...
呵，你不妨贴出你的结果来看看。
我说的没错。
不管是32位还是64位
call 这种形式，不会是5个字节，你认为它是5个字节，说明是你理解错了。
错在：你理解为是：eip +offset 这种形式。这是错误的，所以是5个字节
这是个内存操作数，会依赖于ModRM字节。
所以，call 这条指令正确是6个字节，
在64位下，确实是 rip+offset 这种形式。
但是，不是你说的 address+n32，正确的说是 rip+offset。 rip 并不等于你说的 address0。
同样，在64位下，你也错误地简单理解为32位下的 eip +offset。
在这里，此rip +offset 并不是你理解的 eip+offset ，同样正确来说也是6个字节
以上，就是你的错误之处！
另：我没必要和你较劲！ 我对x86的指令系统很熟悉。你若觉得我不误，贴出结果以证实 原帖由 mik 于 2008-4-24 23:32 发表 http://linux.chinaunix.net/bbs/images/common/back.gif
呵，你不妨贴出你的结果来看看。
我说的没错。
不管是32位还是64位
call 这种形式，不会是5个字节，你认为它是5个字节，说明是你理解错了。
错在：你理解为是：eip +offset 这种形式。这是 ...
补充一点, call 这种形式的指令也有可能 7 个字节，依赖于这个内存操作数的写法，有index register的时候会是7个字节
回复 #32 mik 的帖子
早就看得出大侠对x86的指令系统很熟悉."在64位下，确实是 rip+offset 这种形式。
但是，不是你说的 address+n32，正确的说是 rip+offset。 rip 并不等于你说的 address0。
同样，在64位下，你也错误地简单理解为32位下的 eip +offset。"---大侠这句话说的有点猜测原文的意思.
"在64位下，确实是 rip+offset 这种形式"这一点跟原文一致了,交流的目的达到了.
[ 本帖最后由 system888net 于 2008-4-25 00:26 编辑 ] 顶mik等楼上几位大侠.
每个帖子能这样客观交流就非常好 有个地方没看明白.
64bit
我们有两个地址,指针存放的地址,以及指针指向的目标地址
哪一个是rip+offset??另一个呢??
如果不和rip挂钩,则只能访问0-4G;如果挂钩的话,data和ip挂钩总觉得很别扭
还有这里说的64位是ia64(安腾)还是ia32e(酷瑞2)???
总觉得ia64是一个不大成功的产品,就像vista一样. 原帖由 system888net 于 2008-4-24 23:55 发表 http://linux.chinaunix.net/bbs/images/common/back.gif
早就看得出大侠对x86的指令系统很熟悉.
"在64位下，确实是 rip+offset 这种形式。
但是，不是你说的 address+n32，正确的说是 rip+offset。 rip 并不等于你说的 address0。
同样，在64位下，你也错误地简单 ...
我和你说的是一个意思吗？
我简直是在对牛弹琴，浪费口水。 原帖由 dxcnjupt 于 2008-4-25 16:17 发表 http://linux.chinaunix.net/bbs/images/common/back.gif
有个地方没看明白.
64bit
我们有两个地址,指针存放的地址,以及指针指向的目标地址
哪一个是rip+offset??另一个呢??
如果不和rip挂钩,则只能访问0-4G;如果挂钩的话,data和ip挂钩总觉得很别扭
还有 ...
建议 x86 平台上的 64 位知识，看 AMD 的，AMD 是 x86-64 的先驱，虽然 INTEL 是兼容 AMD
x86-64 有一种寻址是： RIP 依赖寻址
举个例子：
mov rax, ， 在这里这个内存数 就是个 RIP 依赖寻址。
真正的含义是：mov rax，
在64位下是不能这样： mov rax,
若要直接对64位进行寻址的话：
mov rax, 0x1122334455667788
mov rdx,
[ 本帖最后由 mik 于 2008-4-25 18:46 编辑 ] 很久没碰汇编了。我来说说我的看法。
照lz的说法
addr0: call addr0
生成的机器码里offset部分应该是0了。实际不是
这里的rip应该是call 指令下一条指令的地址
我没有64位的环境。在vc里面做了一下32位的实验不知道能不能说明问题
10: int main(int argc, char* argv[])
11: {
00401010 55 push ebp
00401011 8B EC mov ebp,esp
00401013 83 EC 40 sub esp,40h
00401016 53 push ebx
00401017 56 push esi
00401018 57 push edi
00401019 8D 7D C0 lea edi,
0040101C B9 10 00 00 00 mov ecx,10h
00401021 B8 CC CC CC CC mov eax,0CCCCCCCCh
00401026 F3 AB rep stos dword ptr
12: ccc:
13: __asm
14: {
15: call ccc
00401028 E8 FB FF FF FF call ccc (00401028)
16: call bbb
0040102D E8 00 00 00 00 call bbb (00401032)
17:
18:
19: }
20:
21:
22: bbb:
23:
24: return 0;
00401032 33 C0 xor eax,eax
25: }
原帖由 cjaizss 于 2008-4-23 15:19 发表 http://linux.chinaunix.net/bbs/images/common/back.gif
兼容自然是要损失一些东西的，通用，就会损失效率、存储，不通用，就可以提高效率、存储。使用STL自然不可能有你为特定项目特意设计的算法效率高（当然，前提是设计者不是个棒槌）。编码的冗余问题。鱼与熊掌不 ...
简单,精炼~~ 感觉发出这个帖子的人象是井底之蛙：
人家64位系统都自带64位编译器，你还何苦去自己搞。
除非要自己再重新搞个编译器专门自己用，否则没有意义。