stricmp
in [ASM]
|
From: Randall Hyde on 9 Mar 2005 21:23 "Evenbit" <nbaker2328(a)charter.net> wrote in message news:1110419887.907697.67320(a)l41g2000cwc.googlegroups.com... > > procedure stricmp; @nodisplay; @noframe; align(4); > > begin stricmp; > > > > push( ebx ); > > > > > > // Compare the two strings until we encounter a zero byte > > // or until the corresonding characters are different. > > > > cmpLoop: > > > > mov( [esi], al ); > > mov( [edi], ah ); > > add( 1, esi ); > > add( 1, edi ); > > cmp( al, 0 ); > > je notAlpha; > > cmp( al, ah ); > > je cmpLoop; > > OOoops!! I was under the impression there would be more register > preservation code up in here. Now I know why my proggies are still > buggy even after HLA stops complainning at me. Back to the drawing > board... > > Nathan. stricmp isn't a routine you'd normally call in the HLA Standard Library. It's a helper routine that other functions call. In particular, routines like str.ieq, str.ine, str.ilt, etc. Consider, for example, the source code to str.ilt: procedure str.ilt( src1:string; src2:string ); @nodisplay; @noalignstack; begin ilt; push( esi ); push( edi ); mov( src1, esi ); mov( src2, edi ); stricmp(); mov( 0, eax ); setb( al ); pop( edi ); pop( esi ); end ilt; As you can see, esi and edi are preserved here (as they are used to pass parameters on to stricmp. Sorry, you can't blame the HLA stdlib for your woes on this one :-( Cheers, Randy Hyde
From: Frank Kotler on 9 Mar 2005 21:29 Evenbit wrote: > OOoops!! Yeah, yeah, blame it on OOP :) > I was under the impression there would be more register > preservation code up in here. Now I know why my proggies are still > buggy even after HLA stops complainning at me. Back to the drawing > board... Unless I'm mistaken, this code would "normally" be called via a "wrapper" - "str.ieq", e.g. - which *does* preserve esi/edi... and returns a result in eax, not in flags, If you're calling it directly - parameters in esi/edi, not on stack, then you *would* have a problem if you expected esi/edi to be preserved... Best, Frank
From: Randall Hyde on 9 Mar 2005 22:06 "Frank Kotler" <fbkotler(a)comcast.net> wrote in message news:422FB0EE.19B40C96(a)comcast.net... > > Unless I'm mistaken, this code would "normally" be called > via a "wrapper" - "str.ieq", e.g. - which *does* preserve > esi/edi... and returns a result in eax, not in flags, If > you're calling it directly - parameters in esi/edi, not on > stack, then you *would* have a problem if you expected > esi/edi to be preserved... Actually, it *does* return the stricmp result in the flags, though executing code like the following would be bizarre: str.ieq( s1, s2 ); jae s1gts2; Cheers, Randy Hyde
From: Evenbit on 10 Mar 2005 16:02 Randall Hyde wrote: > "Evenbit" <nbaker2328(a)charter.net> wrote in message > news:1110419887.907697.67320(a)l41g2000cwc.googlegroups.com... > > > procedure stricmp; @nodisplay; @noframe; align(4); > > > begin stricmp; > > > > > > push( ebx ); > > > > > > > > > // Compare the two strings until we encounter a zero byte > > > // or until the corresonding characters are different. > > > > > > cmpLoop: > > > > > > mov( [esi], al ); > > > mov( [edi], ah ); > > > add( 1, esi ); > > > add( 1, edi ); > > > cmp( al, 0 ); > > > je notAlpha; > > > cmp( al, ah ); > > > je cmpLoop; > > > > OOoops!! I was under the impression there would be more register > > preservation code up in here. Now I know why my proggies are still > > buggy even after HLA stops complainning at me. Back to the drawing > > board... > > > > Nathan. > > > stricmp isn't a routine you'd normally call in the HLA Standard Library. > It's a helper routine that other functions call. In particular, routines > like > str.ieq, str.ine, str.ilt, etc. Oh, that explains it. Now I gotta go back through the house and turn all the maps, atlases, and globes right-side up again. :) > > Consider, for example, the source code to str.ilt: > > procedure str.ilt( src1:string; src2:string ); @nodisplay; @noalignstack; > begin ilt; > > push( esi ); > push( edi ); > > mov( src1, esi ); > mov( src2, edi ); > stricmp(); > mov( 0, eax ); > setb( al ); > > pop( edi ); > pop( esi ); > > end ilt; > > As you can see, esi and edi are preserved here (as they are used > to pass parameters on to stricmp. Sorry, you can't blame the HLA > stdlib for your woes on this one :-( Correct. I've discovered that my woes are due to confusion about pointers and addressing modes. Somewhere along the way, I've gotten it jumbled and can't see through the fog. I guess, getting accustomed to defining something like this: static stuff: dword[4] := [1,2,3,4]; .. .. then it is easy to see that I access an individual element as: stuff[ecx*4] But when I want to allocate memory from the heap: var aBuff: dword; .. .. mem.alloc(4); //interested in byte data now mov( eax, aBuff ); ....I can't do an "aBuff[ecx]" (or can I??) because the label "aBuff" is a pointer to a pointer. Say I want to step through that chunk of memory a byte at a time and stuff the contents of AL into those four locations. I can do a "mov( aBuff, ebx )" but then both "mov( al, [ebx + ecx] )" and "mov( al, ebx[ecx] )" are illegal. The only solution I see is to forget the count register {ecx} and just increment EBX and stopping when EBX equals aBuff + size_of_aBuff. I must be missing something really simple... but just can't put my finger on it. Nathan.
From: Frank Kotler on 10 Mar 2005 17:14
Evenbit wrote: .... > I can do a "mov( aBuff, ebx )" but then both "mov( al, [ebx > + ecx] )" and "mov( al, ebx[ecx] )" are illegal. When you say "illegal", do you mean HLA won't accept the syntax, or you get an access violation? This is working fine for me! Best, Frank |