Inline asm support and x64 development (Off Topic)

OSR_Community_User · September 30, 2005, 2:53pm

Jason,

I want to make you aware that Microsoft has refrained from supporting inline
assembler code from day 1 with the C++compiler for x64. Microsoft might have
a lot of very good reasons to do so. However it hurt a lot those for a
thousand good reasons (optimization for example) need to use asm code at
kernel as well as user level. At least if Microsoft’s C compiler doesn’t
support inline asm code anymore in x64 let the visual tools integrate the
ml64 compiler nicely in the development tools. It is a pain to integrate asm
file support by hand in the visual studio environment.

I was recently experimenting with the Intel C compiler and happily
discovered that they do nicely support inline asm for x64 development.

Thanks

Guy Bonneau

OSR_Community_User · September 30, 2005, 4:02pm

I can’t be of much help here, but I forwarded your comments over to some
of the compiler guys so they hear your pain. The best I can offer as a
response is that they said:

There are a number of good reasons why we chose not to support inline
asm for x64. But as mentioned below, there has been a fair bit of
customer feedback indicating that people are not happy with this
decision.

Jason

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Guy Bonneau
Sent: Friday, September 30, 2005 11:53 AM
To: Kernel Debugging Interest List
Subject: [windbg] Inline asm support and x64 development (Off Topic)

Jason,

I want to make you aware that Microsoft has refrained from supporting
inline assembler code from day 1 with the C++compiler for x64. Microsoft
might have a lot of very good reasons to do so. However it hurt a lot
those for a thousand good reasons (optimization for example) need to use
asm code at kernel as well as user level. At least if Microsoft’s C
compiler doesn’t support inline asm code anymore in x64 let the visual
tools integrate the ml64 compiler nicely in the development tools. It is
a pain to integrate asm file support by hand in the visual studio
environment.

I was recently experimenting with the Intel C compiler and happily
discovered that they do nicely support inline asm for x64 development.

Thanks

Guy Bonneau

You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · September 30, 2005, 4:58pm

And what are those “good” reasons one might ask ?

I can’t be of much help here, but I forwarded your comments over to
some of the compiler guys so they hear your pain. The best I can offer
as a response is that they said:

There are a number of good reasons why we chose not to support inline
asm for x64. But as mentioned below, there has been a fair bit of
customer feedback indicating that people are not happy with this
decision.

Jason

Don_Burn_1 · September 30, 2005, 6:46pm

“Guy Bonneau” wrote in message
> I want to make you aware that Microsoft has refrained from supporting
> inline
> assembler code from day 1 with the C++compiler for x64. Microsoft might
> have
> a lot of very good reasons to do so. However it hurt a lot those for a
> thousand good reasons (optimization for example) need to use asm code at
> kernel as well as user level.

This is funny, every driver I’ve worked with that had assembler for
optimizations worked better and faster once it was eliminated. There are
reasons to dive into assembler but they are few and far between. I appluad
Microsoft for eliminating the capability, hopefully this will cause people
to think before going the assembler route.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

OSR_Community_User · September 30, 2005, 10:12pm

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

Gary_Little · October 1, 2005, 12:23am

Actually, no … he is not kidding, and having used inline asm myself for
what I perceived to be a good I reason I have to agree with Don. There are
very few reasons that justify inline assembly, and most of those generally
involve the engineers ego.

–
Gary G. Little

“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

David_J_Craig · October 1, 2005, 1:14am

I can see it for a quick and dirty test utility. However, I know that
‘someone’, probably a PHB, will take that test utility and release it in
some critical part of a major product. I do think that it should be
difficult to use it. You forgot to say that inline assembly is not part of
the ‘C’ language. The double underscore indicates that it is a vendor
unique change to the standard. Gary, I know you know this, but someone else
seems to be confused.

It isn’t that difficult to create another source file and have it in the
project. Some have said that it is difficult to build x86 drivers with
build that contain .asm files. I don’t see why, it should be fairly easy to
do with makefile.inc if the standard stuff doesn’t work.

“Gary G. Little” wrote in message news:xxxxx@windbg…
> Actually, no … he is not kidding, and having used inline asm myself for
> what I perceived to be a good I reason I have to agree with Don. There are
> very few reasons that justify inline assembly, and most of those generally
> involve the engineers ego.
>
> –
> Gary G. Little
>
>
> “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
>
>
>

OSR_Community_User · October 1, 2005, 3:31am

Well I see ego here all the time. Which is bad. But that has nothing to
do with whether inline assembly is vile and should not be supported.

Again if you don’t need it, good for ya. You hate it, keep it to
yourself. Your opinion belongs in a thread where people hate it and
don’t want it. But if someone does, don’t think that you know better. So
please…

Don_Burn_1 · October 1, 2005, 6:54am

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

Don_Burn_1 · October 1, 2005, 6:56am

The only ego I see is yours. This has been studied to death, rarely does
one get improvement, and even then you have a pain to keep it optimal. What
is worse, is compilers keep getting better, so while your code may be
somewhat better today, tommorrow the compiler beats your efforts.

–
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…
Well I see ego here all the time. Which is bad. But that has nothing to
do with whether inline assembly is vile and should not be supported.

Again if you don’t need it, good for ya. You hate it, keep it to
yourself. Your opinion belongs in a thread where people hate it and
don’t want it. But if someone does, don’t think that you know better. So
please…

OSR_Community_User · October 1, 2005, 3:43pm

There is another very important application of using inline assembly. It is doing XOR for RAID 5 in a host based raid solution [I have experienced this in Scsi/Stor Miniports but might be applicable for others too]. Try using c code for doing this and I can bet your driver would cry like hell. I have seen it myself and be assured using inline assembly for using the MMX [equivalent in x64 environment] instructions gives at least 20 times more performance for XOR engine. No Ego here just pure performance TURBO boost. If the assembly is gone I do not know how the host based RAID 5 solutions would survive.

Ajitabh

Don Burn wrote:
The only ego I see is yours. This has been studied to death, rarely does
one get improvement, and even then you have a pain to keep it optimal. What
is worse, is compilers keep getting better, so while your code may be
somewhat better today, tommorrow the compiler beats your efforts.

–
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…
Well I see ego here all the time. Which is bad. But that has nothing to
do with whether inline assembly is vile and should not be supported.

Again if you don’t need it, good for ya. You hate it, keep it to
yourself. Your opinion belongs in a thread where people hate it and
don’t want it. But if someone does, don’t think that you know better. So
please…

—
You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

---------------------------------
Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort.

Don_Burn_1 · October 1, 2005, 4:25pm

We all stated there are special cases, and this is exactly the type of thing
you do in a seperate routine. Since MMX uses floating point unit if I
remember correctly, are you counting the cost of the FP save restore in
this?

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Driver Coder” wrote in message
news:xxxxx@windbg…
> There is another very important application of using inline assembly. It
> is doing XOR for RAID 5 in a host based raid solution [I have experienced <br>> this in Scsi/Stor Miniports but might be applicable for others too]. Try
> using c code for doing this and I can bet your driver would cry like hell.
> I have seen it myself and be assured using inline assembly for using the
> MMX [equivalent in x64 environment] instructions gives at least 20 times
> more performance for XOR engine. No Ego here just pure performance TURBO
> boost. If the assembly is gone I do not know how the host based RAID 5
> solutions would survive.
>
> - Ajitabh
>
> Don Burn wrote:
> The only ego I see is yours. This has been studied to death, rarely does
> one get improvement, and even then you have a pain to keep it optimal.
> What
> is worse, is compilers keep getting better, so while your code may be
> somewhat better today, tommorrow the compiler beats your efforts.
>
>
> –
> 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…
> Well I see ego here all the time. Which is bad. But that has nothing to
> do with whether inline assembly is vile and should not be supported.
>
> Again if you don’t need it, good for ya. You hate it, keep it to
> yourself. Your opinion belongs in a thread where people hate it and
> don’t want it. But if someone does, don’t think that you know better. So
> please…
>
>
>
> —
> You are currently subscribed to windbg as: xxxxx@yahoo.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> ---------------------------------
> Yahoo! for Good
> Click here to donate to the Hurricane Katrina relief effort.

Doron_Holan · October 1, 2005, 8:11pm

You can always create your own intrinsic that uses MMX and call that from straight C no?

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Driver Coder
Sent: Saturday, October 01, 2005 12:43 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Inline asm support and x64 development (Off Topic)

There is another very important application of using inline assembly. It is doing XOR for RAID 5 in a host based raid solution [I have experienced this in Scsi/Stor Miniports but might be applicable for others too]. Try using c code for doing this and?I can bet your driver would cry like hell. I have seen it myself and be assured using inline assembly for using the MMX [equivalent in x64 environment] instructions gives at least 20 times more performance for XOR engine. No Ego here just pure performance TURBO boost. If the assembly is gone I do not know how the host based RAID 5 solutions would survive.

Ajitabh

Don Burn wrote:
The only ego I see is yours. This has been studied to death, rarely does
one get improvement, and even then you have a pain to keep it optimal. What
is worse, is compilers keep getting better, so while your code may be
somewhat better today, tommorrow the compiler beats your efforts.

–
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…
Well I see ego here all the time. Which is bad. But that has nothing to
do with whether inline assembly is vile and should not be supported.

Again if you don’t need it, good for ya. You hate it, keep it to
yourself. Your opinion belongs in a thread where people hate it and
don’t want it. But if someone does, don’t think that you know better. So
please…

—
You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
________________________________________
Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort. — You are currently subscribed to windbg as: xxxxx@microsoft.com To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · October 1, 2005, 8:31pm

Look who is talking, I have seen your posts here !!

Hand optimization may be someone’s reason, but that is not what I was
arguing for. There are perfectly valid reasons to do inline assembly
otherwise.

And in case someone is confused asm *is* a keyword in ISO C and C++. And
no I don’t give a rats ass who thinks what. I was seeking MS’s reasons
of not supporting while they support inline assembly in the puny
pocketpc !!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Saturday, October 01, 2005 3:56 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Inline asm support and x64 development (Off Topic)

The only ego I see is yours. This has been studied to death, rarely
does one get improvement, and even then you have a pain to keep it
optimal. What is worse, is compilers keep getting better, so while your
code may be somewhat better today, tommorrow the compiler beats your
efforts.

–
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…
Well I see ego here all the time. Which is bad. But that has nothing to
do with whether inline assembly is vile and should not be supported.

Again if you don’t need it, good for ya. You hate it, keep it to
yourself. Your opinion belongs in a thread where people hate it and
don’t want it. But if someone does, don’t think that you know better. So
please…

—
You are currently subscribed to windbg as: xxxxx@appstream.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · October 1, 2005, 8:42pm

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

OSR_Community_User · October 3, 2005, 9:34am

Don,

I would agree with you that most of the time assembler code doesn’t help
very much at kernel level. As you probably observed yourself adding a few
line of assembler code inside C code rarely improve performance.

I am not talking about a few lines of inline assembler instruction. But I am
talking about a few hundred and sometime thousand of lines of assembler
code. I would say that it is not worthwhile trying to write assembler code
unless you develop an expertise in computer architecture and have a very
good understanding of OOO (Out Of Order) processor scheduling. Beside you
need to have a strong mathematical background to understand how to fit the
algorithm you are working at with the set of instructions the processor
uses.

A good example could be the use of the CMOV instruction. Not a long time ago
I remember when the C compiler of Microsoft couldn’t even use a CMOV
conditional instruction to remove a conditional branching.

I could also point to those who write assembler code for security issues at
kernel level playing with DR registers and writing “virus-like” assembler
code trying to stop hackers.

OSR_Community_User · October 3, 2005, 12:02pm

Yes you can. Never tried that but yes that would be an option to explore. Do you think writing XOR engine itself as intrinsics is viable?

I really have not explored this as a possibility so not comments on this.

Ajitabh

Doron Holan wrote:
You can always create your own intrinsic that uses MMX and call that from straight C no?

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Driver Coder
Sent: Saturday, October 01, 2005 12:43 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Inline asm support and x64 development (Off Topic)

There is another very important application of using inline assembly. It is doing XOR for RAID 5 in a host based raid solution [I have experienced this in Scsi/Stor Miniports but might be applicable for others too]. Try using c code for doing this and I can bet your driver would cry like hell. I have seen it myself and be assured using inline assembly for using the MMX [equivalent in x64 environment] instructions gives at least 20 times more performance for XOR engine. No Ego here just pure performance TURBO boost. If the assembly is gone I do not know how the host based RAID 5 solutions would survive.

- Ajitabh

Don Burn wrote:
The only ego I see is yours. This has been studied to death, rarely does
one get improvement, and even then you have a pain to keep it optimal. What
is worse, is compilers keep getting better, so while your code may be
somewhat better today, tommorrow the compiler beats your efforts.

–
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…
Well I see ego here all the time. Which is bad. But that has nothing to
do with whether inline assembly is vile and should not be supported.

Again if you don’t need it, good for ya. You hate it, keep it to
yourself. Your opinion belongs in a thread where people hate it and
don’t want it. But if someone does, don’t think that you know better. So
please…

—
You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort. — You are currently subscribed to windbg as: xxxxx@microsoft.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

---------------------------------
Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort.

OSR_Community_User · October 3, 2005, 12:21pm

Yes I did count that. The whole point of MMX is to provide performance improvements by doing functions in hardware that used to be done using less-efficient “regular” x86 instructions. According to the MMX documentation you can start using the MMX instructions anytime but you will have to exit the MMX instructions with EMMS. The FPU registers are not saved across the execution of MMX instructions.The CPU does not do that because it is very expensive. So I think you are perfectly safe without the overhead saving the registers and all.

Thanks,
Ajitabh

Don Burn wrote:
We all stated there are special cases, and this is exactly the type of thing
you do in a seperate routine. Since MMX uses floating point unit if I
remember correctly, are you counting the cost of the FP save restore in
this?

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Driver Coder” wrote in message
news:xxxxx@windbg…
> There is another very important application of using inline assembly. It
> is doing XOR for RAID 5 in a host based raid solution [I have experienced <br>> this in Scsi/Stor Miniports but might be applicable for others too]. Try
> using c code for doing this and I can bet your driver would cry like hell.
> I have seen it myself and be assured using inline assembly for using the
> MMX [equivalent in x64 environment] instructions gives at least 20 times
> more performance for XOR engine. No Ego here just pure performance TURBO
> boost. If the assembly is gone I do not know how the host based RAID 5
> solutions would survive.
>
> - Ajitabh
>
> Don Burn wrote:
> The only ego I see is yours. This has been studied to death, rarely does
> one get improvement, and even then you have a pain to keep it optimal.
> What
> is worse, is compilers keep getting better, so while your code may be
> somewhat better today, tommorrow the compiler beats your efforts.
>
>
> –
> 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…
> Well I see ego here all the time. Which is bad. But that has nothing to
> do with whether inline assembly is vile and should not be supported.
>
> Again if you don’t need it, good for ya. You hate it, keep it to
> yourself. Your opinion belongs in a thread where people hate it and
> don’t want it. But if someone does, don’t think that you know better. So
> please…
>
>
>
> —
> You are currently subscribed to windbg as: xxxxx@yahoo.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> ---------------------------------
> Yahoo! for Good
> Click here to donate to the Hurricane Katrina relief effort.

—
You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

---------------------------------
Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort.

OSR_Community_User · October 3, 2005, 12:43pm

Highly specialized (and new) instruction sets such as MMX / XMM / [etc] are
exceptions to this principle. At first, the compiler doesn’t support it.
Then, the compiler supports it but the developer cannot always enable it
because s/he cannot assume that all of the target hardware platforms support
the new extensions. Once critical mass has been reached, then the developer
can assume it’s present, and allow the compiler to use the new instruction
sets. Detecting support at runtime, and providing support for both in the
same platform is a bit more complex, but not impossible.

There’s nothing that prevents people from using assembly – just not mixing
assembly and C in the same file. So what? If you know enough to write
assembly, and have proven to yourself that you can do a better job than a C
compiler, then write it in an assembly file.

– arlie

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Driver Coder
Sent: Saturday, October 01, 2005 3:43 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Inline asm support and x64 development (Off Topic)

There is another very important application of using inline assembly. It is
doing XOR for RAID 5 in a host based raid solution [I have experienced this in Scsi/Stor Miniports but might be applicable for others too]. Try using c
code for doing this and I can bet your driver would cry like hell. I have
seen it myself and be assured using inline assembly for using the MMX
[equivalent in x64 environment] instructions gives at least 20 times more
performance for XOR engine. No Ego here just pure performance TURBO boost.
If the assembly is gone I do not know how the host based RAID 5 solutions
would survive.

Ajitabh

Don Burn wrote:

The only ego I see is yours. This has been studied to death, rarely
does
one get improvement, and even then you have a pain to keep it
optimal. What
is worse, is compilers keep getting better, so while your code may
be
somewhat better today, tommorrow the compiler beats your efforts.

–
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…
Well I see ego here all the time. Which is bad. But that has nothing
to
do with whether inline assembly is vile and should not be supported.

Again if you don’t need it, good for ya. You hate it, keep it to
yourself. Your opinion belongs in a thread where people hate it and
don’t want it. But if someone does, don’t think that you know
better. So
please…

—
You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com

________________________________

Yahoo! for Good
Click here to donate http:</http:> to the
Hurricane Katrina relief effort. — You are currently subscribed to windbg
as: xxxxx@stonestreetone.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

OSR_Community_User · October 3, 2005, 3:05pm

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