News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Testing an odd number

Started by frktons, August 27, 2010, 09:40:15 AM

Previous topic - Next topic

dedndave

actually lingo - i was making the remark and rolling my eyes because of all your nonsense - lol

dedndave

Frank - if the contents of the register are "disposable", you can use SHR
        shr     eax,1
        jc      value_was_odd

the original value may be recovered, if desired with RCL EAX,1
as long as the carry flag has not been altered

frktons

Quote from: dedndave on August 27, 2010, 12:46:55 PM
Frank - if the contents of the register are "disposable", you can use SHR
        shr     eax,1
        jc      value_was_odd

the original value may be recovered, if desired with RCL EAX,1
as long as the carry flag has not been altered

Thanks Dave. Good to know, it's one of the solutions I tested.
What about avoiding the eax MOV and testing the variable directly?

;-------------------------------------------------------------------------------------------------------------------------
; Test if a number is ODD or EVEN
; Date: 27 august 2010
;-------------------------------------------------------------------------------------------------------------------------


INCLUDE \masm32\include\masm32rt.inc

;------------------------------------------------------------------------------------------------------------------------------

.DATA

number    dd    12


;------------------------------------------------------------------------------------------------------------------------------


.CODE


start:

    bt number, 0

    jc  isodd

    print "The number is EVEN",13,10

    inkey

    jmp end_test

isodd:

    print "The number is ODD",13,10

    inkey


end_test:


    ret

end start


Mind is like a parachute. You know what to do in order to use it :-)

frktons

Well testing the number directly has some small advantages:

Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz (SSE4)
2072    cycles for 1000*test eax, 1, result=500
2028    cycles for 1000*bt eax, 0, result=500

2016    cycles for 1000*bt number, 0, result=1000

2041    cycles for 1000*test eax, 1, result=500
2036    cycles for 1000*bt eax, 0, result=500

2025    cycles for 1000*bt number, 0, result=1000


--- ok ---


I tested with number = 13.
Mind is like a parachute. You know what to do in order to use it :-)

lingo

Hi,Frank
"What about avoiding the eax MOV and testing the variable directly?"
Will be faster coz you will skip mov eax, number.

dedndave,
actually dedndave - have you some news  about your wife coz it is not healthy for a man to be alone? :snooty:

frktons

Quote from: lingo on August 27, 2010, 01:02:23 PM
Hi,Frank
"What about avoiding the eax MOV and testing the variable directly?"
Will be faster coz you will skip mov eax, number.

Well, there is infact a quite small advantage as I realized with my test.
Tell me Lingo, do you really think these tests are useless, or are you
just joking?
Mind is like a parachute. You know what to do in order to use it :-)

lingo

Will be better for you to test it. Just make  two algos equal and test them. The times must be the same but I think they will be different... :U

frktons

Quote from: lingo on August 27, 2010, 01:13:19 PM
Will be better for you to test it. Just make  two algos equal and test them. The times must be the same but I think they will be different... :U

On modern OSes, with dozens of tasks around all the time, is almost impossible
to have two equal results. I think we can only have a broad idea of the speed, and
this should be the target of the tests. Thanks anyway for your comments.  :U
Mind is like a parachute. You know what to do in order to use it :-)

jj2007

Quote from: dedndave on August 27, 2010, 12:46:55 PM
the original value may be recovered, if desired with RCL EAX,1
as long as the carry flag has not been altered

Cute, Dave. Didn't know that, probably since OpCodes.chm tells a different story:

QuoteRotates the bits in the destination to the left "count" times with all data pushed out the left side re-entering on the right. The Carry Flag holds the last bit rotated out.

Nothing on carry flag rotating in etc...

But I checked it with Olly, and you are right, as usual :U

dedndave

i am a little surprised, Jochen, that you don't have a solid handle on SH/RO/RC instructions
that's some of the first asm stuff i learned   :P
in the beginning, i didn't have many tools - had to figure out how things worked manually
when i first got a PC, i thought DEBUG was the bees knees - lol

on an 8008, we considered CF to be the "9th bit"   :lol

jj2007

Quote from: dedndave on August 27, 2010, 02:51:19 PM
i am a little surprised, Jochen, that you don't have a solid handle on SH/RO/RC instructions
that's some of the first asm stuff i learned   :P

My solid handles are \masm32\help and Google, and I thought \masm32\help\opcodes.chm was enough. Usually it is correct.

mineiro

Hello Sr frktons;
I'm getting float results here; while at every firsts test "test" wins, but after some 10 tests the result invert and "bt" wins.
If I put some huge program to be load, while doing the test program, this results preserve here. At night I can do more tests to you.
regards.

dedndave

at my age, my solid handles seem to be around my waist - lol
all my life, i have worn slacks and jeans with 34 to 36 waist
had to get some new stuff - 38" now   :lol

jj2007

Quote from: dedndave on August 27, 2010, 12:10:43 PM
hiyas Jochen - good morning (here) - good afternoon (there)

i can't imagine that much difference in speed  :P
must be something wrong with the test   ::)   :lol

Yes, sure! On a P4, test al is three millicycles slower:
Intel(R) Pentium(R) 4 CPU 3.40GHz (SSE3)
4034    1000*test eax, 1, result=500
4037    1000*test al, 1, result=500
10676   1000*bt eax, 0, result=500


By the way: Lingo is so quiet. I think he is cooking up an SSE5 version that runs in -50 cycles - on his CPU only :green2

P.S.:
> had to get some new stuff - 38" now   :lol
My condolencies - I know the problem :thumbu

P.P.S.: For those who draw their skills from OpCode.chm, here a "second opinion" (MasmReference):
QuoteRCL/RCR/ROL/ROR Rotate
Rotates the bits in the destination operand the number of times specified in the
source operand. RCL and ROL rotate the bits left; RCR and ROR rotate right.
ROL and ROR rotate the number of bits in the operand. For each rotation, the
leftmost or rightmost bit is copied to the carry flag as well as rotated. RCL and
RCR rotate through the carry flag. The carry flag becomes an extension of the
operand so that a 9-bit rotation is done for 8-bit operands, or a 17-bit rotation
for 16-bit operands.

On the 8088 and 8086, the source operand can be either CL or 1. On the
80186–80486, the source operand can be CL or an 8-bit constant. On the
80186–80486, rotate counts larger than 31 are masked off, but on the 8088 and
8086, larger rotate counts are performed despite the inefficiency involved. The
overflow flag is modified only by single-bit variations of the instruction; for
multiple-bit variations, the overflow flag is undefined.

bomz

masm32 applications limits by windows procedure, and serious code optimization needs only for huge computation.



whether there Patch to remove this header ?