amd64 and vs.net 2005

[Shawn B.]

Will the final release get inline assembly? It seems a bit odd to allow it
for 32-bit but not 64-bit one there are so many optimaztions that can be
done. It seems strange to have to code the whole function in asm just to
have about 5 lines of asm in a 200 line code block... I'm supposing it is
just because its beta at the moment and asking specifically if there are
plans to enable the feature for the final release?


Thanks,
Shawn

 

[Carl Daniel [VC++ MVP]]

Will the final release get inline assembly? It seems a bit odd to
allow it for 32-bit but not 64-bit one there are so many optimaztions
that can be done. It seems strange to have to code the whole
function in asm just to have about 5 lines of asm in a 200 line code
block... I'm supposing it is just because its beta at the moment and
asking specifically if there are plans to enable the feature for the
final release?

Over on microsoft.private.whidbey.cplusplus.codegen,

It is unlikely that we'll go down the path of inline assembly on any
of the 64-bit platforms. Your alternatives are to use the appropriate
compiler intrinsics or to write assembly in separate ASM files and
use ML to assemble them.

That's as close to an authoritative answer as I'm aware of.

-cd

 

[Shawn B.]

May I ask, does it have anything to do with not wanting to support 2
different instruction sets (Itanium/AMD64)?


Thanks,
Shawn

 

[Carl Daniel [VC++ MVP]]

May I ask, does it have anything to do with not wanting to support 2
different instruction sets (Itanium/AMD64)?

I would assume it has more to do with a large amount of effort to implement
inline assembly and releatively little usage.

Granted, inline asm is a Godsend when it's what you need, but the vast
majority of C/C++ code contains no inline assembly, so it's probably pretty
far down on the priority list for getting resources assigned to it.

-cd

 

[Ioannis Vranos]

Will the final release get inline assembly? It seems a bit odd to allow it
for 32-bit but not 64-bit one there are so many optimaztions that can be
done. It seems strange to have to code the whole function in asm just to
have about 5 lines of asm in a 200 line code block... I'm supposing it is
just because its beta at the moment and asking specifically if there are
plans to enable the feature for the final release?

I can't answer about AMD64 etc assembly instructions support, but do you
know the Common Intermediate Language (CIL), also known as Intermediate
Language (IL) or in MS world (MSIL)?


It is the assembly language of the CLI VM (in the MS case, .NET).


I think this is the assembly language that makes sense in the managed world.


A book on it:

http://www.amazon.com/exec/obidos/search-handle-form/104-1372924-4177557



About this assembly language, as far as I know it will not be possible
to use it in some other language source code, but only in separate
source code files.


Perhaps this is the case for "native" assembly languages too.

 

[Ioannis Vranos]

I can't answer about AMD64 etc assembly instructions support, but do you
know the Common Intermediate Language (CIL), also known as Intermediate
Language (IL) or in MS world (MSIL)?


It is the assembly language of the CLI VM (in the MS case, .NET).


I think this is the assembly language that makes sense in the managed
world.


A book on it:

http://www.amazon.com/exec/obidos/t...f=sr_1_1/104-1372924-4177557?v=glance&s=books



About this assembly language, as far as I know it will not be possible
to use it in some other language source code, but only in separate
source code files.


Perhaps this is the case for "native" assembly languages too.

 

[Gabest]

I would assume it has more to do with a large amount of effort to
implement inline assembly and releatively little usage.

I miss inline assembly too...

When you say it is hard to implement, do you mean it is hard to get in sync
what the assembly uses and what the compiler generates? (ie. if programmer
uses eax, then the compiler has to avoid or save eax before the __asm block)

Or perhaps translating references to symbols is harder in the 64 bit word?
(int i = 0; __asm eax, i

I cannot think of any more reasons right now (but I don't write the compiler
either , but if there aren't many more, then why we can't have naked
functions at least?

 

[Carl Daniel [VC++ MVP]]

When you say it is hard to implement,

I didn't say it was hard, I speculated that it's a lot of effort. Modern
processors have 100's of instructions and 1000's of legal opcode patterns -
implementing an inline assembler for them is going to be a lot of work.

do you mean it is hard to get
in sync what the assembly uses and what the compiler generates? (ie.
if programmer uses eax, then the compiler has to avoid or save eax
before the __asm block)
Or perhaps translating references to symbols is harder in the 64 bit
word? (int i = 0; __asm eax, i

I cannot think of any more reasons right now (but I don't write the
compiler either , but if there aren't many more, then why we can't
have naked functions at least?

I'd suggest you post both requests as suggestions at the MSDN Produce
Feedback Center.

http://lab.msdn.microsoft.com/productfeedback/

-cd

 

[Gabest]

I'd suggest you post both requests as suggestions at the MSDN Produce
Feedback Center.

http://lab.msdn.microsoft.com/productfeedback/

-cd

Done.

http://lab.msdn.microsoft.com/produ...edbackid=f6d309ee-6aec-4969-9618-1fdd338f036d

 

[Shawn B.]

I voted, too.

http://lab.msdn.microsoft.com/produ...edbackid=f6d309ee-6aec-4969-9618-1fdd338f036d

 

[Shawn B.]

Traditionally, every C/C++ compiler that I know of (at least have used or
had some exposure to) supported inline asm. It is very handy, especially
when writing emulators. Now, I want to port my stuff to 64-bit native and
it seems I have to rewrite about 70% of it in pure asm because I use inline
asm where it makes sense and it is in quite a few places and in doing so, I
got some massive performance increases in the 32-bit world. I'm not about
to rewrite my stuff in pure 64-bit asm just because of that. However, there
are other compilers like GCC that likely support the feature, I'll just
change my code to work with an alternate compiler and ignore VC++ 64-bit if
that's what it takes, it's a pity, because it is a great development
invironment that I'm quite familiar with.

In this case, I'm not concerned about .NET or IL (for these projects)
although I am a C# programmer. I'm not bummed that IL isn't supported in
those languages as there are symantecs and politics involved. But this is
the first modern C/C++ compiler I've heard of that doesn't support inline
assembly. For example, this recently released book makes a great case for
using inline asm for optimizing VC++ 2003 code:

http://tinyurl.com/4fxz5 [Amazon Book ISBN: 193176932X]

Anyway, I hope they get the feature, I doubt I'm the only one that uses it.
Combine that with the lack of documentation for the ML64 and I'm beginning
to think they don't want asm programmers anymore with their tools.


Thanks,
Shawn

 

[Ioannis Vranos]

Traditionally, every C/C++ compiler that I know of (at least have used or
had some exposure to) supported inline asm. It is very handy, especially
when writing emulators.

Yes, after all the C++ standard provides the keyword asm:


"7.4 The asm declaration

An asm declaration has the form

asm-definition:
asm ( string-literal ) ;

The meaning of an asm declaration is implementation- information
through the implementation to an assembler. ]"

Now, I want to port my stuff to 64-bit native and
it seems I have to rewrite about 70% of it in pure asm because I use inline
asm where it makes sense and it is in quite a few places and in doing so, I
got some massive performance increases in the 32-bit world. I'm not about
to rewrite my stuff in pure 64-bit asm just because of that. However, there
are other compilers like GCC that likely support the feature, I'll just
change my code to work with an alternate compiler and ignore VC++ 64-bit if
that's what it takes, it's a pity, because it is a great development
invironment that I'm quite familiar with.

In this case, I'm not concerned about .NET or IL (for these projects)
although I am a C# programmer. I'm not bummed that IL isn't supported in
those languages as there are symantecs and politics involved.

..NET is supported in C++, if you are saying that.

But this is
the first modern C/C++ compiler I've heard of that doesn't support inline
assembly. For example, this recently released book makes a great case for
using inline asm for optimizing VC++ 2003 code:

http://tinyurl.com/4fxz5 [Amazon Book ISBN: 193176932X]

Anyway, I hope they get the feature, I doubt I'm the only one that uses it.
Combine that with the lack of documentation for the ML64 and I'm beginning
to think they don't want asm programmers anymore with their tools.

Myself agree that inline "native" assembly should be supported along
with inline IL assembly for hand optimisation.

 

[Ioannis Vranos]

Yes, after all the C++ standard provides the keyword asm:

"7.4 The asm declaration

An asm declaration has the form

asm-definition:
asm ( string-literal ) ;

The meaning of an asm declaration is implementation-defined. [Note:
Typically it is used to pass information
through the implementation to an assembler. ]"

Now, I want to port my stuff to 64-bit native and
it seems I have to rewrite about 70% of it in pure asm because I use
inline
asm where it makes sense and it is in quite a few places and in doing
so, I
got some massive performance increases in the 32-bit world. I'm not
about
to rewrite my stuff in pure 64-bit asm just because of that. However,
there
are other compilers like GCC that likely support the feature, I'll just
change my code to work with an alternate compiler and ignore VC++
64-bit if
that's what it takes, it's a pity, because it is a great development
invironment that I'm quite familiar with.

In this case, I'm not concerned about .NET or IL (for these projects)
although I am a C# programmer. I'm not bummed that IL isn't supported in
those languages as there are symantecs and politics involved.

.NET is supported in C++, if you are saying that.

But this is
the first modern C/C++ compiler I've heard of that doesn't support inline
assembly. For example, this recently released book makes a great case
for
using inline asm for optimizing VC++ 2003 code:

http://tinyurl.com/4fxz5 [Amazon Book ISBN: 193176932X]

Anyway, I hope they get the feature, I doubt I'm the only one that
uses it.
Combine that with the lack of documentation for the ML64 and I'm
beginning
to think they don't want asm programmers anymore with their tools.

Myself agree that inline "native" assembly should be supported along
with inline IL assembly for hand optimisation.

 

[Jochen Kalmbach]

Hi Carl Daniel [VC++ MVP],

I'd suggest you post both requests as suggestions at the MSDN Produce
Feedback Center.

A better feature would be the support of inline IL asm!!!


--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

 

[Shawn B.]

That would be useful, as well. But it won't help in converting a 32-bit app
that is an emulator that uses lots of inline asm to speed itself up
(significantly over the compiler) when porting to 64-bit. I'm looking at
having to re-write lots of it in 64-bit asm because of not allowing
inlining. Took me a year to write it in the first place. Or, I have to
figure out how I'm going to re-organize my code. I might have 200-300 lines
of C++ code in some functions and about 8 lines of asm or even 30... but
now, I'll have to lose all the C++ and make it all asm, considering that
support for inline asm is a part of the C++ standard, and they are pushing
to be standards compliant, then this shouldn't be ommitted. Perhaps they
are just being lazy.

However, I agree, inline IL would be useful, but not at the expense of
inline asm. I suppose there aren't any "backwards compatibility" issues
here but there are portability issues. It is far easier to port 32-bit apps
to 64-bit apps (that use inline asm) if inline asm is supported. I'm less
likly to port any of my important things over to 64-bit if it means I have
to re-write 70% of it just because I made the unfortunate decision to use
inline asm to achieve a 30-50% performance increase in the 32-bit world
where those same techniques are not supported on the 64-bit platform (in
some cases I achieved a 150% performance increase by using inline asm). So
it does have value.

I was looking forward to porting my stuff to 64-bit now I dread it because
of all the work it'll cause me and I just don't have that much time.


Thanks,
Shawn

Hi Carl Daniel [VC++ MVP],

I'd suggest you post both requests as suggestions at the MSDN Produce
Feedback Center.

A better feature would be the support of inline IL asm!!!


--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

 

[Ronald Laeremans [MSFT]]

Please let us know the kind of patterns of code you need to write in
assembly on IA64, x86 or x64 for performance reasons. In our analysis of
internal MS code these patterns are extremely rare, so we are very
interested in seeing any patterns where we need to improve our
optimizations.

The answers given above are right on, it is a lot of effort to support
inline assembler (e.g. just think about the need to add the completely new
mechanism to support bundles for IA64 assembler) and both the frequency and
the availability of good alternatives (mostly a combination of the stand
alone assembler and intrinsics will be as good a solution or even a better
one) lead us to prioritize this feature quite low.

Ronald Laeremans
Visual C++ team

That would be useful, as well. But it won't help in converting a 32-bit
app
that is an emulator that uses lots of inline asm to speed itself up
(significantly over the compiler) when porting to 64-bit. I'm looking at
having to re-write lots of it in 64-bit asm because of not allowing
inlining. Took me a year to write it in the first place. Or, I have to
figure out how I'm going to re-organize my code. I might have 200-300
lines
of C++ code in some functions and about 8 lines of asm or even 30... but
now, I'll have to lose all the C++ and make it all asm, considering that
support for inline asm is a part of the C++ standard, and they are pushing
to be standards compliant, then this shouldn't be ommitted. Perhaps they
are just being lazy.

However, I agree, inline IL would be useful, but not at the expense of
inline asm. I suppose there aren't any "backwards compatibility" issues
here but there are portability issues. It is far easier to port 32-bit
apps
to 64-bit apps (that use inline asm) if inline asm is supported. I'm less
likly to port any of my important things over to 64-bit if it means I have
to re-write 70% of it just because I made the unfortunate decision to use
inline asm to achieve a 30-50% performance increase in the 32-bit world
where those same techniques are not supported on the 64-bit platform (in
some cases I achieved a 150% performance increase by using inline asm).
So
it does have value.

I was looking forward to porting my stuff to 64-bit now I dread it because
of all the work it'll cause me and I just don't have that much time.


Thanks,
Shawn

Hi Carl Daniel [VC++ MVP],

I'd suggest you post both requests as suggestions at the MSDN Produce
Feedback Center.

A better feature would be the support of inline IL asm!!!


--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

 

[Gabest]

I did a little testing myself and the compiler turned out pretty smart in
64bit mode (in 32bit mode it often couldn't keep all variables in
registers). But if I may ask why do xmm6 through xmm9 get saved onto the
stack? They don't need to be preserved at all, according to my knowledge.

 

[Gabest]

One more thing.

I'm not sure whether this trick still works on newer cpu's, but these two
paired instructions become reodered almost every time:

movaps xmm1, xmm0
pshufd xmm3, xmm2, 0e4h