The MASM Forum

General => The Campus => Topic started by: apinheiro on January 26, 2013, 05:19:20 AM

Title: looping
Post by: apinheiro on January 26, 2013, 05:19:20 AM
Hi,
i'm new to Assembly.
I wan't to create a loop, presenting a message n-times. But i'm not getting the thing to work.
Code

.386
.model flat, stdcall
option casemap :none

include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
include \masm32\include\masm32.inc

includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\masm32.lib

.data
    ola db "Ola Mundo!", 0
 

.code

start:
    ;inicializar o contador a 6
    mov ecx,6
    ;limpar o registo eax
    ;xor eax, eax
    ;
;add eax, ecx
repetir:   
    dec ecx
    ;push ecx
    invoke StdOut, addr ola
   
    ;pop ecx
    jnz repetir
   
    invoke ExitProcess, 0
end start

I also tryied using stack as you can see but is not working either.
Thanks in advance
Title: Re: looping
Post by: bomz on January 26, 2013, 05:25:25 AM
.386

.model flat, stdcall
option casemap :none

include \MASM32\INCLUDE\windows.inc
include \MASM32\INCLUDE\user32.inc
include \MASM32\INCLUDE\kernel32.inc
includelib \MASM32\LIB\user32.lib
includelib \MASM32\LIB\kernel32.lib

.data
mestitle db "Bomz",0
form db "EAX: %010hu", 0

.data?
buffer db 512 dup(?)

.code
start:
mov ecx, 3
@@:
push ecx
invoke wsprintf,ADDR buffer,ADDR form,ecx
invoke MessageBox,0,ADDR buffer,ADDR mestitle,MB_ICONASTERISK
pop ecx
loop @B
invoke ExitProcess,0
end start


@echo off
color 0a
cd /d %~dp1
C:\masm32\bin\ml.exe /c /coff "%~1"
C:\masm32\bin\link.exe /subsystem:windows "%~n1.obj"
del "%~n1.obj"
pause
Title: Re: looping
Post by: qWord on January 26, 2013, 05:27:13 AM
The flags does change during the call to StdOut. Saving ECX with PUSH/POP was right.

mov ecx,count
l1:
    push ecx
    ; call API
    pop ecx
    dec ecx
    jnz l1


EDIT: bomz , LOOP is obsolet!
Title: Re: looping
Post by: bomz on January 26, 2013, 05:35:28 AM
dec ecx need more ticks on my proccessor too - sub ecx, 1. there is no need in such space economy
Title: Re: looping
Post by: apinheiro on January 26, 2013, 06:29:21 AM
Thank you all!

I get it working. :)
Title: Re: looping
Post by: jj2007 on January 26, 2013, 06:31:52 AM
Quote from: bomz on January 26, 2013, 05:35:28 AM
dec ecx need more ticks on my proccessor too - sub ecx, 1.

Have you timed it, or are you just guessing?

By the way, loop instead of dec ecx/jnz slows down a loop that prints a single character by 0.04%, but it is one byte shorter. It might be the one byte that makes the code cache overflow in the innermost loop that follows printing ;-)
Title: Re: looping
Post by: Gunther on January 26, 2013, 06:37:25 AM
Hi Jochen,

Quote from: jj2007 on January 26, 2013, 06:31:52 AM
Quote from: bomz on January 26, 2013, 05:35:28 AM
dec ecx need more ticks on my proccessor too - sub ecx, 1.

Have you timed it, or are you just guessing?

By the way, loop instead of dec ecx/jnz slows down a loop that prints a single character by 0.04%, but it is one byte shorter. It might be the one byte that makes the code cache overflow in the innermost loop that follows printing ;-)

do you really think that?

Gunther
Title: Re: looping
Post by: qWord on January 26, 2013, 06:46:49 AM
bomz,
learn ENGLISH and RTFM.
You will find a explicit warning in AMD's documentation - for Intel just look up the latency :shock:
Title: Re: looping
Post by: jj2007 on January 26, 2013, 07:26:56 AM
Quote from: Gunther on January 26, 2013, 06:37:25 AM
do you really think that?

Gunther,

it's not a matter of thinking, it's a measurement matter.

Of course, one would never use loop or lodsb etc in an innermost loop that runs ten Million times. You also won't find them in library functions like strcmp or len etc, because you never know if there is a user who needs to squeeze out the last cycle in a tight loop. But in a loop that contains something as horribly slow as invoke StdOut, it's often the most convenient solution to use these old instructions (and yes, in rare cases it can even speed up code due to less cache usage).

Of course, if Intel and AMD officially announce that they won't work in the next processor generation, then it would be time to drop them. Around 2050, I guess.