News:

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

.REPEAT .BREAK .UNTIL

Started by ic2, March 06, 2008, 11:40:24 AM

Previous topic - Next topic

Jimg

I really don't intend to muddy the waters here, but technically and semantically,

.break jumps out of the loop (either .while or .repeat) it is inside, just past the .until or .endw.
.continue jumps to the part of the loop where it checks for the terminating condition.

Rainstorm

what is this code from the masm hlp doing exactly with .break .if   or should the .endw statement be right at the bottom
EXAMPLE
    mov eax, 100
    .while eax > 0
      sub eax, 1
    .endw

    msgloop:
      invoke GetMessage, ADDR msg,NULL,0,0
      .break .if eax == 0

      invoke TranslateMessage, ADDR msg
      invoke DispatchMessage,ADDR msg
    jmp msgloop

Tedd

I don't know what that mess is ::)

The normal message loop would be:
    .WHILE TRUE
        invoke GetMessage, ADDR msg,NULL,0,0
        .BREAK .IF (eax == 0)
        invoke TranslateMessage, ADDR msg
        invoke DispatchMessage, ADDR msg
    .ENDW


Which translates to:
    @while:
        invoke GetMessage, ADDR msg,NULL,0,0
        test eax,eax
        jz @out
        invoke TranslateMessage, ADDR msg
        invoke DispatchMessage, ADDR msg
        jmp @while
    @out:
No snowflake in an avalanche feels responsible.

Rainstorm

Tedd, thanks for clearing that & the code examples.

just one more question... : ) can the masm .break be used in an masm  switch block ?

in the win SDK there is this example
case WM_CONTEXTMENU:
    if (!OnContextMenu(hwnd, GET_X_LPARAM(lParam),
              GET_Y_LPARAM(lParam)))
        return DefWindowProc(hwnd, uMsg, wParam, lParam);
    break;


why is the break after the return there ? what sense does that make ?

jj2007

Made a quick test with Olly:

nop
    .WHILE TRUE
        dec eax
        .BREAK .IF (eax == 0)
    .ENDW
nop
    .WHILE 1
        dec eax
        .BREAK .IF (eax == 0)
    .ENDW
nop
    .REPEAT
        dec eax
        .BREAK .IF (eax == 0)
    .UNTIL 0
nop
    .REPEAT
        dec eax
        .BREAK .IF (eax == 0)
    .UNTIL FALSE
nop

... translates to ...
00403FFE     90             NOP
00403FFF   > 48             DEC EAX
00404000   . 0BC0           OR EAX,EAX
00404002   . 74 02          JE SHORT ReTest.00404006
00404004   .^EB F9          JMP SHORT ReTest.00403FFF
00404006   > 90             NOP
00404007   > 48             DEC EAX
00404008   . 0BC0           OR EAX,EAX
0040400A   . 74 02          JE SHORT ReTest.0040400E
0040400C   .^EB F9          JMP SHORT ReTest.00404007
0040400E   > 90             NOP
0040400F   > 48             DEC EAX
00404010   . 0BC0           OR EAX,EAX
00404012   . 74 02          JE SHORT ReTest.00404016
00404014   .^EB F9          JMP SHORT ReTest.0040400F
00404016   > 90             NOP
00404017   > 48             DEC EAX
00404018   . 0BC0           OR EAX,EAX
0040401A   . 74 02          JE SHORT ReTest.0040401E
0040401C   .^EB F9          JMP SHORT ReTest.00404017
0040401E   > 90             NOP


Masm doesn't care whether you use .while TRUE or .while 1, and produces exactly the same code for the equivalent .rep until true... clever  :thumbu

jj2007

Quote from: Rainstorm on March 08, 2008, 08:41:30 PM
just one more question... : ) can the masm .break be used in an masm  switch block ?
nope - Masm chokes
Quote
in the win SDK there is this example
case WM_CONTEXTMENU:
    if (!OnContextMenu(hwnd, GET_X_LPARAM(lParam),
              GET_Y_LPARAM(lParam)))
        return DefWindowProc(hwnd, uMsg, wParam, lParam);
    break;


why is the break after the return there ? what sense does that make ?

It doesn't make any sense, but certain C dialects allow "falling through". Shiver :tdown

Rainstorm

QuoteIt doesn't make any sense, but certain C dialects allow "falling through". Shiver ThumbsDown
l o l ! at the *shiver*....masm is the only  language I've ever looked at & am trying to learn, so don't know anything about C

many thanks for clearing that up.



jj2007

Apparently Java is also affected by that:

Common sense would indicate that after executing the instructions following a case statement, and having come across another case statement the compiler would then finish falling through the switch statement. However, for reasons best known to the designers of the language case statements only stop falling through when they come across a break statement.

http://www.jchq.net/tutorial/02_01Tut.htm

The designers of Java and C also had the bright idea that a ";" must tell their compilers that a linefeed will soon follow, and that flow control must be controlled by many many "{" and "}" characters. Try a Google search on "C programming" "repetitive stress injury"  :wink

BogdanOntanu

Quote from: jj2007 on March 09, 2008, 09:37:51 AM
Apparently Java is also affected by that:

Common sense would indicate that after executing the instructions following a case statement, and having come across another case statement the compiler would then finish falling through the switch statement. However, for reasons best known to the designers of the language case statements only stop falling through when they come across a break statement.

And I have seen many modern software that DOES use this feature (falling through the switch statement). For some desperate mental reason they do consider it "cool" and an acceptable programming practice. Also there are many programmers out there that consider that the more complicated and more special features of the compiler they use and the more obfuscated the code is ... the more intelligent they are.

It is also related to not loosing your job. If it take a long time for a new employee to understand your code (and the code is perfectly valid) they your job is "more safe".

Quote
The designers of Java and C also had the bright idea that a ";" must tell their compilers that a linefeed will soon follow, and that flow control must be controlled by many many "{" and "}" characters. Try a Google search on "C programming" "repetitive stress injury"  :wink

That way it is more easy for the parser ... :D

Rainstorm:
Maybe you should take a look at other programming languages also. Of course there is no thing like ASM but a good programmer should also know C and a few other programming languages. At least in order to be able to read code that demonstrates some algorithms.
Ambition is a lame excuse for the ones not brave enough to be lazy.
http://www.oby.ro

Tedd

Quote from: Rainstorm on March 08, 2008, 08:41:30 PM
just one more question... : ) can the masm .break be used in an masm  switch block ?

in the win SDK there is this example
case WM_CONTEXTMENU:
    if (!OnContextMenu(hwnd, GET_X_LPARAM(lParam),
              GET_Y_LPARAM(lParam)))
        return DefWindowProc(hwnd, uMsg, wParam, lParam);
    break;


why is the break after the return there ? what sense does that make ?

The masm 'switch' block is really just a macro that rewrites to an .if block; a compiled switch statement can be more complicated. Since there was no 'break' included with that macro set, it won't work (because it's really just inside an if, but then, it's not required either.)
The win sdk examples are mainly in C++, and standard C requires a break to end the current 'case' -- making it jump to the end of the switch statement (after all of the other 'cases.') C++ and Java copied the fall-through format mainly for compatibility (execution 'falls' into the next case's code unless there is a break to stop that.)
In that example, the break comes 'after' return because the return is actually inside the if (i.e. if true: return, else break.)
No snowflake in an avalanche feels responsible.

BogdanOntanu

Quote
In the win SDK there is this example
Code:
case WM_CONTEXTMENU:
    if ( !OnContextMenu(hwnd, GET_X_LPARAM(lParam),GET_Y_LPARAM(lParam)) )
    {
              return DefWindowProc(hwnd, uMsg, wParam, lParam);
    }
    break;

why is the break after the return there ? what sense does that make ?

For C/C++ it makes perfect sense. That is because the return statement will be executed only if the if condition is true. Since there is no else statement then the code might still fall through on some situations. Hence the break statement is required unless the original programmer intended a fall through and in this case I do not think he did.
Ambition is a lame excuse for the ones not brave enough to be lazy.
http://www.oby.ro

Rainstorm

ted, thx ..... that explaination was really helpfull.

bogdan, yes.. maybe i'll try a  high level language sometime. - at the moment am just trying to learn asm & in the process, reading & trying out stuff in the windows SDK that is quite vast & time consuming. - I've not so much as looked at any other language before starting out with asm- I usually kinda get the logic of the code examples in the sdk broadly speaking , ..in order to duplicate the functionality in asm,  but not everything as i don't know the syntax.

..appreciate the help all.

Rainstorm
-