hmmm... i'm worken my way through some tuts, tryin to get my feet wet with asm... and I'm comin accross stuff like .WHILE TRUE and .ENDIF, and stuff like that. And I seem to remember sein a post somewhere (if i could remember where it was I wouldn't be posting this :P), that refered to these things as kind of a... replacement, or something, for jumps (which I know nothing about as yet). So is this something i'm going to have to un-learn later on? and of course, if it is... where might i find some info on jumps (yes, i know that chances are i'm horribly mis-using the word 'jump' here... like i said... very new to asm)?
Posted on 2002-02-18 14:50:40 by TheGreatTriscuit
It is macro/pseudos-instructions...
It is made as a replacement for some comparisons and loops to have a better program readability...
I used them a bit, now I avoid them... and IMHO, with a cmp/je sequence to code a wndproc in example, you have an as good readability, and i find it personally better (looks like some macros from Windowsx.h in C)
Posted on 2002-02-18 15:20:32 by JCP
Here is some info on controlling program flow with .IF, .WHILE and more in MASM.
Party on :alright:

http://webster.cs.ucr.edu/Page_TechDocs/MASMDoc/ProgrammersGuide/Chap_07.htm
Posted on 2002-02-18 15:26:47 by NoException
right on... thanks guys...

btw... i think " :alright: " has got to be one of the coolest UBB codes i've seen :P
Posted on 2002-02-18 16:29:11 by TheGreatTriscuit
Triscuit,

Don't lose any sleep over using the pseudo high level stuff in MASM while you are learning, it will get you a lot of code written with far fewer bugs and you can experiment at your leasure with manual conditional testing.

The rough distinction is you use the .IF/.WHILE stuff in operating system based code like WndProc procedures and other non critical stuff where the logic is more important but in high speed algorithms, you normally use the comparisions that are done manually.

Regards,

hutch@movsd.com
Posted on 2002-02-18 19:34:08 by hutch--
Triscuit,

one of the main advantages (IMHO) of the .IF and .WHILE statements is being able to have several conditions on the same line, like this:

Posted on 2002-02-18 21:40:34 by sluggy
If you add the /Sg option to the ML command line, you can see the code generated by .IF .WHILE, and the other built-in macros like INVOKE, in your listing file. The .LISTALL directive also shows you the generated code.

:)
Posted on 2002-02-18 22:08:31 by S/390
Does somebody know how to only have the generated code and not the bunch of includes / equates ? (windows.inc, ie, makes the listing grow up, slow the building down and makes it not easy to follow at all...

Thanks.
Posted on 2002-02-19 01:10:42 by JCP
Readiosys,

I assem with /Sg (if I want to see generated code) and /Sn (turns off the symbol table at the end of the listing). I put a .NOLIST before the INCLUDEs and a .LIST after them. :)
Posted on 2002-02-19 02:14:59 by S/390
Fine ! Thanks for the trick. ;)
Posted on 2002-02-19 02:17:26 by JCP
To TheGreatTriscuit:
I'm going to start working on long ago promissed FLAGS And JCC
tutor. When it is ready I'll send it here.

May I ask you a question?
Why did you come to write in asm?
What brought you to it?
Posted on 2002-02-19 10:47:31 by The Svin
thanks for the help guys...

(and sluggy, that was... frightening... :P)

and Svin... I'm learning assembly for a few reasons. My own personal satisfaction being the primary one. I also figure it'll give me a better idea as to how computers work at a really low level (and it is). I'd been toying around with the thought of learning asm for a while, but I had been under the impression that it would require a great deal of re-inventing the wheel to get even the simplist of tasks done. When i found out that you could use include files and link to librarys and stuff, I decided to at least give it a shot.

And then theres the fact that the only language i'm actually profficient in is VB, and I absolutely despise(sp?) having to distribute all its DLLs for even the simplist of programs. Yes, i know I could use C++ or something similar, but it wouldn't be as 'educational', or fun for that matter. :P

And yes, a tutorial on flags and such would be appreciated :P. I've got the general concept down, but could definitely use a little more direction :P
Posted on 2002-02-19 13:26:04 by TheGreatTriscuit
You might want to learn C and asm at the same time... they go
very well in hand.
Posted on 2002-02-19 13:30:23 by f0dder
To TheGreatTriscuit:
What shell do you use?
Do you use debugger?
Posted on 2002-02-19 13:53:19 by The Svin
shell? I'm assuming you mean IDE, correct me if i'm wrong, and i'm bouncing back n' forth between RadASM and ASMEdit, tryin to see which one I like. So far I like RadASM better, but I'm still undecided.

And no, I dont use a debugger. But thats simply because the code i've written so far has been largely tutorial based, and my errors have all been typos as opposed to faulty logic (so far), so I haven't NEEDED one yet. However, I'm certain I will eventually. probably soon. Any suggestions?

(and i'll keep that in mind f0dder)
Posted on 2002-02-19 14:06:02 by TheGreatTriscuit
Good free debugger = OllyDbg. Doesn't do symbolic debugging iirc,
but that's usually fine if you can narrow down the problem. Softice
is good when you need The Power (TM). Visual studio debugger
is probably the best symbolic debugger I've seen yet.
Posted on 2002-02-19 14:21:36 by f0dder
Triscuit,

Just be careful about learning assembler using the assumptions of any other language, it has a power and logic of its own that is always compromised with lesser languages.

Sink in the low level stuff where you can because it will improve your direct coding in assembler instructions. Alex's suggestion of a tutorial on conditional jumps (Jcc) and flags will be welcome by many and you will find this knowledge very useful in coding algorithms.

Regards,

hutch@movsd.com
Posted on 2002-02-19 14:23:00 by hutch--
OK our goal is to learn how the machine works.
I have some good news and one bad news for you then.
Good:
1. How machine works you can see only in debugger. Run the programm,
though it written with MASM32, can not show you how machine works - it
can only show the results of working.
So the 1st good news is - now you know where to look to see how machine
work (though to see doesn't meen to understand - but we manage it in very shor time)
and you now will not waste your time trying to figure out it by simple app writing\runing

2. It is very easy to find and set debugger in any shell you use (including easy and fast
Hutch shell supplied in MASM32)
To load some prog in debugger you need just add the name of the prog in command line
after debugger name.
For example TD32.exe MyProg.exe.
Here are easy few steps how to do loading your prog into debugger in RadAsm by
JUST ONE KNEY STROKE!
- Find debugger. f0dder mantioned good and free one
you can find it here http://home.t-online.de/home/Ollydbg
- Put it directory with is in path variable (so you can debug any exe file write from where it is)
- Open in RadAsm Option\Tools Menu
- Insert new Menu item
- in field of Menu item write: Debug
- choose accelerator for example: Ctrl+D
- in field of Command write: ollydbg.exe,$.exe
$ here means name of current project, comma is separator for command line params.

Now you can load programm you working on right in debugger by pressing ctrl+D.
So it's 2nd good news - few minutes and you can start watching how the machine works

3. To learn new commands, triks, asm teqnics etc. you absolutly don't need to write full programs
each time you need to learn something
Create simple program project.
Without rc dlgs etc. just asm file.
include just windows.inc and kernel32.inc with kernel32.lib
write in code section:
.code
Start:
call ExitProcess ; need for right loading
end Start
Now you can write any asm instructions between Start: and call ExitProcess, compile and press ctrl-D
to see how instruction works.

F8 - main key (along with F7)
means execute one instruction and stop.
for example you can write between Start: and call ExitProcess
mov eax,1234ABCDh
bswap eax
then
1 compile
2 press Ctrl+D
3 use F8 looking how value in eax on first step becomes 1234ABCDh
and on the second CDAB3412h

you want to learn now other instruction - just replace the two lines with new commands compile and
load into debug.
Actually you can write commands right in debugger without recompiling and loading.

But stop...
Shall I continue?
Posted on 2002-02-19 16:29:21 by The Svin
I'd actually suggest NOT using a debugger. The main reason is they show you too much detail, like trying to 'debug' a cake recipy with an atomic spectrum analysis. Sure, you have all the info there, but no organization.

I much prefer a few macros to emit info where and when I think I need it. In the that my program GPFs and dies (not very rare at all), I'll just emit garbage lables till I get close to the offending line, then emit one per line. Once I know what statement GPF's, its usually pretty simple to see why. If it's not simple, I'll emit every calling value (did I really just pass NULL as the return value array pointer?)

I have some macros I like to use, they will emit to message boxes (highly annoying), a dos box (very convienent if you can start your code from a dos line, not as great for say dll's), or a text file (will always work, I needed this for a COM dll running out of VB).

Hutch has his own dll for this purpose, he sticks info around the main window, such as the status line. Either way has advantages and disadvantages, mostly personal taste.
Posted on 2002-02-19 17:16:22 by Ernie
I agree with Ernie here, a debugger can be more hinderance than help while learning assembler in win32. While they are useful tools, they are mainly useful debugging kernel mode code and device drivers where you have no other means of getting the output you need.

To understand the architecture of current processors, the manufacturers have the best available data so downloading the Intel manuals are good value in both instruction reference and heavyweight technical data.

Testing code at runtime has many advantages and it is no big deal to do, it can get a value for you in difficult places like the middle of a callback, anywhere in the message handler and you can format the output any way you like.
In the simple sense, displaying output on the title bar or status bar is easy to do and fast to set up.

A debugger will never find programming logic errors. only your own grey matter will do that and the closer you can get to it in your own code, the faster you will find it.

Regards,

hutch@movsd.com
Posted on 2002-02-19 17:35:27 by hutch--