strcpy当初没有考虑到的地方

原创 2007年09月19日 21:24:00

strcpy当初没有考虑到的地方

原贴地址:
http://eparg.spaces.live.com/blog/cns!59BFC22C0E7E1A76!1498.entry
原贴时间:
2006-08-16
原贴作者:
eparg
 

当年的讨论在:

http://eparg.spaces.live.com/blog/cns!59BFC22C0E7E1A76!533.entry

http://eparg.spaces.live.com/blog/cns!59BFC22C0E7E1A76!875.entry

最开始考虑strcpy的性能的时候,只考虑了要4bytes一起拷贝。但是忽略了一个关键问题,就是如何判断字符串的结束。由于字符串可以从4bytes中任意一个byte结束,所以需要判断是否有任何一个byte为0。
如果对一个4bytes拆分成4个byte分别判断,那4bytes一起拷贝节省下拉性能立刻浪费掉了。今天看到Newer2k的回复,才重新开始考虑这个问题。
拿到C++的strcpy函数一看,源代码如下:

mov     edi,[esp+8]         ; edi points to dest string
 
copy_start::
       mov     ecx,[esp+0ch]       ; ecx -> sorc string
       test    ecx,3               ; test if string is aligned on 32 bits
       je      short main_loop_entrance
src_misaligned:                     ; simple byte loop until string is aligned
       mov     dl,byte ptr [ecx]
       add     ecx,1
       test    dl,dl
       je      short byte_0
       mov     [edi],dl
       add     edi,1
       test    ecx,3
       jne     short src_misaligned
       jmp     short main_loop_entrance
main_loop:                          ; edx contains first dword of sorc string
       mov     [edi],edx           ; store one more dword
       add     edi,4               ; kick dest pointer
main_loop_entrance:
       mov     edx,7efefeffh
       mov     eax,dword ptr [ecx] ; read 4 bytes
       add     edx,eax                                  
       xor     eax,-1
       xor     eax,edx
       mov     edx,[ecx]           ; it's in cache now
       add     ecx,4               ; kick dest pointer
       test    eax,81010100h
       je      short main_loop
       ; found zero byte in the loop
; main_loop_end:
       test    dl,dl               ; is it byte 0
       je      short byte_0
       test    dh,dh               ; is it byte 1
       je      short byte_1
       test    edx,00ff0000h       ; is it byte 2
       je      short byte_2
       test    edx,0ff000000h      ; is it byte 3
       je      short byte_3
       jmp     short main_loop     ; taken if bits 24-30 are clear and bit
                                   ; 31 is set
byte_3:
       mov     [edi],edx
       mov     eax,[esp+8]         ; return in eax pointer to dest string
       pop     edi
       ret
byte_2:
       mov     [edi],dx
       mov     eax,[esp+8]         ; return in eax pointer to dest string
       mov     byte ptr [edi+2],0
       pop     edi
       ret
byte_1:
       mov     [edi],dx
       mov     eax,[esp+8]         ; return in eax pointer to dest string
       pop     edi
       ret
byte_0:
       mov     [edi],dl
       mov     eax,[esp+8]         ; return in eax pointer to dest string
       pop     edi
       ret
 
这里对一个DWORD (EAX)的判断方法是:
 
1. 对EAX+0x7efefeff
2. 对EAX取反
3. 把1和2的结果作XOR,然后跟0x81010100h作test运算
 
研究了好久,理解如下:
 
问题的关键点在于,当且仅当EAX四个byte都不为0的时候,运算结果会是下面的pattern:

0??? ???0 ???? ???0 ???? ???0 ???? ????
 
分别解释如下:
 
如果第一个byte为0, 考虑第二个byte的最后一个bit。不管这个bit是0还是1,计算公式是:
(x+0) XOR (!x) =x xor !x=0

如果第一个byte不为0,肯定产生进位,考虑第二个byte的最后一个bit。不管这个bit是0还是1,计算公式是:
(x+1)XOR(!x)=!x xor !x=1
 
这就是上面0??? ???0 ???? ???0 ???? ???0 ???? ????第二个byte的第一个bit是0的来历
 
同理,第二,三,四个byte中的的第一个bit的0也是在前面所有的byte都不为0的时候才会出现,否则就会出现至少一个1
 
最后再来看最一个byte的最高位。根据前面的分析,我们已经可以确保前面三个byte为0的pattern。所以我们只需要考虑前面三个byte都不是0,然后检测最后一个byte是否为0的情况。这里分成三种情况来考虑最高一个bit的情况:
 
1) 最高byte为0
由于前面三个byte都不是0,所以相加后最高byte肯定拿到一个进位,所以最高byte的加法变成了跟7f相加。所以公式:
(0+0) XOR (!0) =1
 
2) 最高byte不为0,最高bit为0。这种情况下跟7f相加,相加结果最高bit肯定会变成1:
1 XOR (!0) =0
 
3) 最高byte不为0,最高bit为1。这种情况下跟7f相加,不管相加后最高为是0还是1,都有:
1 XOR (!1) =0
0 XOR (!1) =0
 
所以,如果EAX最高byte为0,结果的最高bit为1. 如果EAX最高byte不为0,结果最高的bit为0
 
综上,如果所有四个byte都不为0,最后得到的pattern是:
0??? ???0 ???? ???0 ???? ???0 ???? ????
 
于是我们可以拿结果跟0x81010100 作TEST运算,当且仅当四个byte都不为0的时候,ZR寄存器的值为0。
 
大家注意看,我上面的分析有一个错误!
 
1 XOR (!1) =0
 
错了,这里应该是1
 
换句话说,上面的代码无法区分最高一个byte最高bit为0,其他bit为1的情况。这是这种算法的一个死穴。当出现比如0x80112233这样的DWORD的时候,test    eax,81010100h 计算的结果跟0x00112233一样。当然最后的结果不会有问题,因为byte_3 -- byte_0里面会再次作判断。所以,如果用一连串的0x80112233作为字符串内容,strcpy的效率会大大下降
 
谢谢newer2k帮我找到我分析中的错误!
 
 
另外一种解释可以参考:
http://www.programfan.com/club/showtxt.asp?id=141040

strlen讲解和快速确定字符串结束符的位置

strlen源码剖析快速确定字符串结束符位置 整理分别来自于下面的文章。 http://code.google.com/p/strstrsse/source/browse/trunk/ http...
  • rjs123
  • rjs123
  • 2012年06月08日 11:44
  • 916

看看str系列函数的实现 一

很多面试题都会提到自己来实现一个函数,strcmp,strcpy,strstr……我们来看一下一下函数的实现:intstrcmp (p1, p2)     const char *p1;     co...

strstr strlen strcpy函数实现

strcpy函数实现 strcpy 看似是标准函数库里面最简单的函数了,谁都可以实现这个函数,   但是,并不一定谁都能实现的很好。林锐博士面试微软的时候,就做这个题目。   他也没有把这个题目...

考虑到内存覆盖的strcpy实现

已知strcpy函数的原型是: char *strcpy(char *dst, const char *src); 实现strcpy函数解释为什么要返回char *假如考虑dst和src内...

C++研究之在开发中你可能没有考虑到的两个性能优化

 1:多余的存储引用导致性能降低; 2:利用局部性提高程序性能; 先来说说引用是怎么降低程序性能,个人认为降低程序性能主要有两个原因,一是数据结构选择不合理,二是多层嵌套循环导致部分代码被多...

移动APP服务端API设计应该考虑到的问题

2014年,移动APP的热度丝毫没有减退,并没有像桌面软件被WEB网站那样所取代, 不但如此,越来越多的传统应用、网站也都开始制作自己的移动APP,也就是我们常说的IOS客户端、android客户端...

系统设计之初应该考虑到的问题

转自:白菜

移动APP服务端API设计应该考虑到的问题

1、跨平台性 所谓跨平台是指我们的接口要能够支持不同的终端,比如android、ios、windowsphone以及桌面软件、网站等, 一套接口,支持多端,就像当年Java的口号一样“Writ...
  • ntotl
  • ntotl
  • 2016年08月03日 15:25
  • 465

谈 DevOps 自动化时,也应该考虑到 SOX 等法案

【编者按】对很多创业公司而言,随着业务的增长,网站的流量也会经历不同的阶段。从十万流量到一百万流量,再从一百万流量跨越到一千万甚至上亿的流量,网站的架构需要经历哪些变化?我们一起听听 58 同城的技术...

UIScrollview要加载大量数据的时候,考虑到内存的消耗问题,我们不可能全部加载完。

因此,需要找到个方法去延迟加载(lazily load), 9160_ScrollerDemo.zip (164.69 KB, 下载次数: 42) ,在测试时发现图片都加载到了内存中,导致内存...
  • yu0089
  • yu0089
  • 2012年10月29日 11:47
  • 5834
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:strcpy当初没有考虑到的地方
举报原因:
原因补充:

(最多只允许输入30个字)