This example means nothing. It’s not that a single “asm” statement disables
optimization globally. It’s that “asm” statements force the compiler to
make extremely conservative assumptions when it is doing data-flow analysis
and call analysis, and also in register usage. A more meaningful example
would contain a function with a significant number of local variables, doing
non-trivial things, and would show that the compiler must assume that
registers *could* have been modified by the “asm” block, and will therefore
reload local variables into registers, etc.
– arlie
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Satya Das
Sent: Monday, October 03, 2005 3:05 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Inline asm support and x64 development (Off Topic)
It seems some have expressed doubts about this ie. continue to believe that
introducing inline assembly basically disables optimization. So here is an
example just to demonstrate this. I compiled this in .NET
2003 -
int SimpleFunc(int param1, int param2)
{
if (2 > param1)
return param1-param2;
else
return param1;
}
int _tmain()
{
//_asm nop;
return SimpleFunc(5, 3);
}
Optimization disabled main looked like this (/Od and sans /Og)
_main:
00401016: 55 push ebp
00401017: 8B EC mov ebp,esp
00401019: 90 nop
0040101A: 6A 03 push 3
0040101C: 6A 05 push 5
0040101E: E8 DD FF FF FF call _SimpleFunc
00401023: 59 pop ecx
00401024: 59 pop ecx
00401025: 5D pop ebp
00401026: C3 ret
With optimization main looked like this
_main:
00401000: 6A 05 push 5
00401002: 58 pop eax
00401003: C3 ret
With inline assembly and optimizations main looked like this
_main:
00401000: 90 nop
00401001: 6A 05 push 5
00401003: 58 pop eax
00401004: C3 ret
Whole program optimization was turned off for this example. You can try more
inline assembly if you are enterprising. But the conclusion is this,
functions with inline assembly *do* get optimized.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Satya Das
Sent: Saturday, October 01, 2005 5:42 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Inline asm support and x64 development (Off Topic)
Your statement about how optimizer behaves with functions with inline
assembly is wrong. In general, functions do get optimized even with inline
assembly. Optimizer in fact may not know in some platforms/tool versions
whether a function was partly inline assembly or not.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Saturday, October 01, 2005 3:54 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Inline asm support and x64 development (Off Topic)
I’m not kidding, I used to be a compiler guy. When you go with inline
assembler the first thing the compiler recognizes is that it cannot safely
optimize. So that clever set of assembler instructions in the middle of the
function, makes the whole function unoptimized. Second, do you really know
the fastest approach for things? Good compilers work like crazy on this.
The scary thing on this is, I’ve been doing compilers and operating systems
for 30 years. I’ve had this argument that long, with the results when
someone REALLY CHECKED always being the same, get rid of the assembler.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting Remove StopSpam from the
email to reply
“Satya Das” wrote in message news:xxxxx@windbg…
You are kidding right ? I am sure the improvements were not because assembly
was used, but because of other factors. In any case there is a reason why
inline assembly was put in the language of C. As long as I have the choice I
am good.
>This is funny, every driver I’ve worked with that had assembler for
optimizations worked better and faster >once it was eliminated.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting Remove StopSpam from the
email to reply
—
You are currently subscribed to windbg as: xxxxx@appstream.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: xxxxx@appstream.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com