Ok ... so I started coding some asm based on what i've read. Trust me I find myself lookup things more then actually typing. Anyway, what I did was write some C in MSVC ... just a simple array and loops and manipulating the array values. Nothing special. In debug mode ... MSVC asm code looks like the code I'm used too.
However, when I do a build and look at the asm that MSVC generates...its completely different then what was in the disassembler. Granted its a release build ... but it even references things differently (ie dword ptr is now lArray and some funky syntax)
is this standard? or is this just MS taking their own crap and converting it?
However, when I do a build and look at the asm that MSVC generates...its completely different then what was in the disassembler. Granted its a release build ... but it even references things differently (ie dword ptr is now lArray and some funky syntax)
is this standard? or is this just MS taking their own crap and converting it?
MSVC debug builds have built-in debug infos in them, so it is able to find the variable name and all...
But when you compile it as release, it does some serious code optimizations in terms of speed and code size and there is no longer debug info in this executable and only code machine can be found in it...
dword ptr is probably where your array is, as a function local variable.
MS is doing things perfectly well here: seeing functions and variable names is just a feature because it is much simple when debugging, but that's all...
But when you compile it as release, it does some serious code optimizations in terms of speed and code size and there is no longer debug info in this executable and only code machine can be found in it...
dword ptr is probably where your array is, as a function local variable.
MS is doing things perfectly well here: seeing functions and variable names is just a feature because it is much simple when debugging, but that's all...
Chances are the release code doesn't contain debug info (it bloats the exe, and can slow stuff down). So the code you are seeing is the actual code the compiler produces, not the beautified, easy to read, source code that you produced.
If you produces some assembly code in masm and assemble using the following command line:
<masm path>\ml /c /coff /Fllist.lst /Sa /Sn <source code>.asm
This will produce a list.lst file which shows pretty much what is REALLY going on with the assembler. How things like rets get expanded into ret 04, or ret nn depending on the number of arguments in the process it is returning from...
MASM hides things from you that you don't really need to worry about when programming. But once you've got a firm grip on the basics, you should really learn them too so you know what actually happens when you create a stack frame, and when you execute a call.
Once you've learned all this stuff you can then put it to the back of your mind until you want to create some heinous, and bastardised hand crafted function.
Mirno
If you produces some assembly code in masm and assemble using the following command line:
<masm path>\ml /c /coff /Fllist.lst /Sa /Sn <source code>.asm
This will produce a list.lst file which shows pretty much what is REALLY going on with the assembler. How things like rets get expanded into ret 04, or ret nn depending on the number of arguments in the process it is returning from...
MASM hides things from you that you don't really need to worry about when programming. But once you've got a firm grip on the basics, you should really learn them too so you know what actually happens when you create a stack frame, and when you execute a call.
Once you've learned all this stuff you can then put it to the back of your mind until you want to create some heinous, and bastardised hand crafted function.
Mirno