RE: code optomization:any way to do this better?

  • From: "Sina Bahram" <sbahram@xxxxxxxxx>
  • To: <programmingblind@xxxxxxxxxxxxx>
  • Date: Mon, 17 Jan 2011 11:33:10 -0500

Look at the link I sent before. That's a good book I think.

Take care,
Sina

-----Original Message-----
From: programmingblind-bounce@xxxxxxxxxxxxx 
[mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Littlefield, Tyler
Sent: Monday, January 17, 2011 11:08 AM
To: programmingblind@xxxxxxxxxxxxx
Subject: Re: code optomization:any way to do this better?

Really? I have a small reference I'm looking at, but it's lacking and 
doesn't exactly explain what it takes. Short of the intel manuals (which 
are actually somewhat readable now in adobe, but still a pain in the ass 
to navigate), what do you suggest as a good reference?

On 1/17/2011 9:06 AM, Sina Bahram wrote:
> Oh, gosh! I forgot the most obvious optimization. There's op-codes to do 
> this, lol.
>
> Essentially, there's a single opcode or two that will actually perform this 
> entire code.
>
> Take care,
> Sina
>
>
>
>
> -----Original Message-----
> From: programmingblind-bounce@xxxxxxxxxxxxx 
> [mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Ken Perry
> Sent: Sunday, January 16, 2011 10:53 PM
> To: programmingblind@xxxxxxxxxxxxx
> Subject: RE: code optomization:any way to do this better?
>
> I don't think there is a really good way to speed this up.  The fact is most
> assemblers will turn this into some really optimized machine code and with
> chips now days they can do multiple look ahead if statements so that this
> would almost happen in one pulse of a chips timing. I think Sina might be
> able to talk on the speed of this better than I but I can tell you the code
> is not bad.  You have to understand  Asm is different than most languages
> because its normal to have some repetitive code.  You could make a block
> that tests for null and returns you to a passed in location so that way
> every time you wanted to test for null you jump to your test block and then
> if its null jump to end or jump back to the location in the code where you
> wanted to be but I don't see any gain in doing that.
>
> Ken
>
>
> -----Original Message-----
> From: programmingblind-bounce@xxxxxxxxxxxxx
> [mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Littlefield,
> Tyler
> Sent: Sunday, January 16, 2011 9:56 PM
> To: programmingblind@xxxxxxxxxxxxx
> Subject: code optomization:any way to do this better?
>
> So I've been playing with assembly a lot lately, and was curious if
> there was a better way to do this. most importantly, the whole three
> branched if check (null, not null).
> section .text
> global _strcmp
> _strcmp:
> enter 0,0
> ;we copy our arguments to EBX and ECX
> mov EBX, [EBP+8]
> mov ECX, [EBP+12]
> .loop:
> ;we need one value in a register
> mov EDX, [ECX]
> ;check for null termination
> cmp byte [EBX], 0
> je .null
> jne .notnull
> ;we have a null termination.
> ;if the other string is null terminated, we jump to success. otherwise
> it fails because they obviously aren't equal.
> .null:
> cmp byte [ECX], 0
> je .success
> jne .fail
> ;byte wasn't null, now we check for null on the other byte.
> ;if one is null, it's a fail because again they aren't equal. If it is
> not null, we do another check.
> .notnull:
> cmp byte [ECX], 0
> ;not equal, we check for equalness between the two now.
> jne .check
> je .fail
> ;we check for equalness between the two bytes here.
> .check:
> cmp [EBX], EDX
> je .next
> jne .fail
> ;here we increase pointers and jump back up to the top of the loop.
> .next:
> inc EBX
> inc ECX
> jmp .loop
> ;strings compared fully
> .success:
> mov EAX,1
> jmp .finish
> ;strings did not compare fully.
> .fail:
> mov EAX, 0
> ;code cleanup.
> ;no need for a jmp, it just falls through.
> .finish:
> leave
> ret
>


-- 

Thanks,
Ty

__________
View the list's information and change your settings at 
//www.freelists.org/list/programmingblind

__________
View the list's information and change your settings at 
//www.freelists.org/list/programmingblind

Other related posts:

  1. Home
  2. programmingblind
  3. Archive
  4. 01-2011