Linked by David Adams on Sun 14th Aug 2011 22:41 UTC, submitted by subterrific
General Development The final ISO ballot on C++0x closed on Wednesday, and we just received the results: Unanimous approval. The next revision of C++ that we've been calling "C++0x" is now an International Standard! Geneva will take several months to publish it, but we hope it will be published well within the year, and then we'll be able to call it "C++11."
Thread beginning with comment 485019
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Yet another standard...
by gilboa on Mon 15th Aug 2011 08:06 UTC in reply to "RE[3]: Yet another standard..."
gilboa
Member since:
2005-07-06

The place of assembly code is in .s/.asm files.

Regarding the other complaints you will find similar issues with other compiler vendors.


You got to be kidding. Have you actually read your own comment before pressing "Submit"?
If the place for in-line assembly is .asm/.s files (says who exactly?), why do ***ALL*** major compilers, including visual C itself, support in-line assembly, outside that is, Visual Studio 64bit (2K5/8/10)?

As for the rest of my comments, nice going! instead of answering them point to point you simply waved, mumbled something about "everybody does that" and continued. You *really* showed me!

- Gilboa

Edited 2011-08-15 08:08 UTC

Reply Parent Score: 3

RE[5]: Yet another standard...
by dpJudas on Mon 15th Aug 2011 08:53 in reply to "RE[4]: Yet another standard..."
dpJudas Member since:
2009-12-10

If the place for in-line assembly is .asm/.s files (says who exactly?), why do ***ALL*** major compilers, including visual C itself, support in-line assembly, outside that is, Visual Studio 64bit (2K5/8/10)?


It is very simple really. Microsoft decided that porting the in-line assembly code to support 64 bit was too much work. So they decided not to bother since in-line assembly really complicates the optimization stages of the compiler. And since the days when in-line assembly was "invented", compiler vendors realized that creating intrinsic functions was a much better solution.

The intrinsic functions have the key advantage that they can be optimized further by the compiler, which means things like register management and memory locations for variables can still be controlled by the usual optimization stages.

This means that some SSE2 code that is written with assembly will have to be re-written for x64 if you want to take advantage of the new set of registers, while the version using intrinsics will simply have to be recompiled. The intrinsic version also just works on GCC, Intel's compiler, MINGW, LLVM. This is also not the case for assembly.

Now if you still believe you're so pro that you can outsmart the compiler's optimization stages, then surely moving your code to an .asm file and doing the x64 function prolog should be a trivial one-time problem, right?

Reply Parent Score: 2

RE[6]: Yet another standard...
by gilboa on Mon 15th Aug 2011 09:02 in reply to "RE[5]: Yet another standard..."
gilboa Member since:
2005-07-06

Now if you still believe you're so pro that you can outsmart the compiler's optimization stages, then surely moving your code to an .asm file and doing the x64 function prolog should be a trivial one-time problem, right?


*Sigh*
10 words, small letters:
memory barriers, lock variants, special ops, per-cpu/platform variant.

- Gilboa

Edited 2011-08-15 09:04 UTC

Reply Parent Score: 2

moondevil Member since:
2005-07-08

"The place of assembly code is in .s/.asm files.

Regarding the other complaints you will find similar issues with other compiler vendors.


You got to be kidding. Have you actually read your own comment before pressing "Submit"?
If the place for in-line assembly is .asm/.s files (says who exactly?), why do ***ALL*** major compilers, including visual C itself, support in-line assembly, outside that is, Visual Studio 64bit (2K5/8/10)?
"

Yes I did read it. Inline assembly in code had its place in the early 80's, when I got started into programming.

In the projects I have lead responsibilities, assembly code if it is required at all, lives in .s/.asm files.

I have seen too many bad examples of C compilers used as assemblers.

As for the rest of my comments, nice going! instead of answering them point to point you simply waved, mumbled something about "everybody does that" and continued. You *really* showed me!

- Gilboa


Well, who said I thought it was important to discuss the remaining points?

Reply Parent Score: 2