home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.asm.x86      Ahh, the lost art of x86 assembly      4,675 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 2,727 of 4,675   
   wolfgang kern to Benjamin David Lunt   
   Re: another stricmp()   
   27 Jun 17 10:01:46   
   
   From: nowhere@never.at   
      
   Benjamin David Lunt wrote:   
      
   > Hi guys,   
   >   
   > Along with the other stricmp() thread, where as the task is to   
   > make it fast, how about I change it slightly for something I   
   > am working on.   
   >   
   > I need a small stricmp() in a real mode boot loader.   
   >   
   > See the code at the end of this post for what I have so far.   
   > Requirements:   
   >  16-bit real mode (32-bit instructions okay)   
   >  Intel x86 assembly (obviously)   
   >  ds:si->string0 (is asciiz and *not* guaranteed to be uppercase)   
   >  es:di->string1 (is asciiz and *not* guaranteed to be uppercase)   
   >  cx = length of string1 (not counting null terminator)   
   > return:   
   >   al -1 if string0 < string1 (or) string0[cx] != '\0'   
   >   al  0 if string0 = string1   
   >   al  1 if string0 > string1   
      
   >    
   > One thing I thought of is to change the uppercase() to simply   
   > set/clear bit 5 in the char before the compare.  For example:   
      
   >  A = 01000001b   
   >  a = 01100001b   
   >   
   > I could simply do an   
   >   
   >  or  al,00100000b   
   > or   
   >  and al,~00100000b   
   >   
   > instead of   
   >   
   >  call uppercase   
      
   > and this would save the size of the two call instructions   
   > as well as the uppercase() procedure, minus the size of two   
   > new 'or/and' instructions.   
   >   
   > (even better:   
   >   and  ax,~0010000000100000b   
   > now that the two chars are in ah and al)   
      
   > However, is this guaranteed to work?  Will setting bit 5 falsely   
   > change a char from a non-alpha character to an alpha character.   
   > No I don't think so.  This should work...   
   >    
      
   If your strings contain also numbers then a OR 0x20 would work   
   while AND 0xDF wont.   
   But if your strings are allowed to contain anything else than A..Z,   
   a..z, 0..9 then both (AND and OR) will fail without proper filters.   
      
   >    
   > In my boot code, I only care if it is equal or not, so no need   
   > for the double compare (two jcc's).  However, I would like to keep   
   > this routine somewhat standard so that I can call it from other   
   > code without any assumptions.   
   >    
      
   > Anyway, what do you guys think?  I can shrink an x86 listing   
   > for size but I don't have much knowledge on x86 speed, hence   
   > I have not commented on the other stricmp() thread. :-)   
      
   > Thanks,   
   > Ben   
      
   you already mentioned it: replace the calls with OR 0x20,   
   and I wouldn't use HLL-styled return values.   
      
   As for speed:   
   * avoid partial register stalls, ie: start with mov dl,[es:di].   
   * LODSB and LOOP are convenient short, but not fast at all.   
   * I'd move the two less/above branches out of the loop (ie: JNZ).   
   * xor al,al   
     cmp [si],al   will cause a dependency stall.   
   But shouldn't the Z-check be within the loop before the OR anyway ?   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca