Doesn't the latest Visual Studio Service Pack update the VC6 compiler?
Posted on 2004-06-01 12:57:29 by Vortex
certainly NOT to the point of vc2003... adds a couple of things, fixes a few bugs, etc... but vs2003 = nearly full ISO C++ compliance, and pretty hardcore optimizations (even if not always at the level of intel C++, it's still miles better than the rest.)
Posted on 2004-06-01 14:55:38 by f0dder
Thanx guys! I still believe you need to give the compiler the right information to make the best use of it! For example, using UINT instead of int's! I like my VC6 though :tongue: What's the diffs between VC2001/2002 and VC2003 in terms of enhancements? I have the 'older' VC.NET. I HATE the entire concept of a 20MB '.NET framework'. Everything you make is an object. Object of an Object of another Object. We really need a HLL or C++ forum! :confused: I still believe assembler programmers make the best HLL programmers, but too many of us are unaware of how to get the most out of HLL's, such as C/C++. Not only with compiler/linker options, but also in our source code. Having a HLL or C forum will allow us to bridge that gap! Integration to HLL's, or the use thereof, or just using HLL's by themselves is essential to the vast majority of assembler programmers! And by not having an area to ask/post HLL or C specific questions, makes me feel less comfortable asking those questions! If we don't learn more about HLL's, we can be considered hipocrites (spelling?) for 'blaming' them for 'not knowing' what assembler can do, when we ourselves don't reallise the potential of some HLL's or compilers. We still hold the advantage though, but that doesn't mean we go through life blindly. Every language has it's uses, or it wouldn't be around. Every language has pro's and con's! Anyway, sorry! I'd just love to have a HLL forum, or even a C/C++ specific forum, because I don't feel comfortable asking my questions on HLL forums!

Regards
Posted on 2004-06-02 01:22:54 by SubEvil
I still believe you need to give the compiler the right information to make the best use of it! For example, using UINT instead of int's


Very true.

I still believe assembler programmers make the best HLL programmers


Yes, asm programmers will understand what goes on during the compiling process, so they will know what 'the right information' is.

Integration to HLL's, or the use thereof, or just using HLL's by themselves is essential to the vast majority of assembler programmers!


Sadly a lot of asm programmers do not give HLLs the credit they deserve, or they are 't00 l33t' to use a HLL.

Every language has it's uses, or it wouldn't be around.


Not every language, I mean... Take Delphi... Please! :)

Anyway, there is a group of programmers that knows both HLLs and asm... A lot of game programmers do. You will often find such people on graphics-related forums.
I suppose graphics is an area where you cannot get by without knowing how to write supertight code. The hardware is always too slow ;)
Posted on 2004-06-02 01:44:30 by Scali

I still believe you need to give the compiler the right information to make the best use of it!

Indeed... It can certainly make a difference how you construct a FOR loop, or the way you access arrays (complex indexing vs. simple pointers). So, for performance-critical pieces of code, you should always have a look at what your compiler generates, and try playing around a bit. This will lead you to a better understanding of your compiler, and to write better code not only at the hot-spots.


What's the diffs between VC2001/2002 and VC2003 in terms of enhancements?

Various performance enhancements, and iirc the /arch:{sse,sse2} was introduced in vc2003. Also, vc2003 improved a lot wrt. the ISO C++ conformance, and is now one of the most conforming compilers. This won't matter for a lot of people, but if you use funky things like templates, especially partial instantation or whatever it's called, it will matter.


I HATE the entire concept of a 20MB '.NET framework'. Everything you make is an object. Object of an Object of another Object.

*shrug*. You don't need to write .NET apps just because you use the .NET compiler :)
Posted on 2004-06-02 09:33:11 by f0dder

Yes, asm programmers will understand what goes on during the compiling process, so they will know what 'the right information' is.
As it turns out, they don't. They can critique the code quality. But to know what the right information is, you actually need to know compiler technology, to understand why some transformations do or do not happen.

There was some discussion of compiler optimization at the masmforum board. If you want to discuss compiler optimizations on this board, we can do it in Heap.
Posted on 2004-06-02 15:01:56 by tenkey
Hey, if it is better than VC++ 6.0 then I'm in for sure, I could use some optimizations in my SMS emulator. I wont be able to use the compiler switches in Visual Studio 6.0 though, is there a list of compiler switches available? and do I have to do anything different to compile the project. I can just hit F7 in VC++ and the project will compile as is like the old VC 6.0 compiler?

I am still trying to figure out why Microsoft would do this?
Posted on 2004-06-02 15:06:09 by x86asm
VS.Net is better than VC++6 -- I've been using it in beta since it came out (free with magazine disk). It should be an easy migration from VC++6 stuff. The optimizations are really good - some global improvements that would be almost impossible to manage from ASM alone.
Posted on 2004-06-02 15:49:36 by bitRAKE
the compiler switches are mostly the same, with a few added - if you overwrite the compiler+linker EXEs, I guess you should be able to use the exact same compiler switches. Adding *new* switches would require using the "manual parameters" box (or however it's named), but that's no biggie.

"Global Optimizations" and "link-time code generation" are pretty interesting!
Posted on 2004-06-02 18:22:47 by f0dder
As it turns out, they don't. They can critique the code quality. But to know what the right information is, you actually need to know compiler technology, to understand why some transformations do or do not happen.


But that is not what I meant. What I meant is that asm programmers will choose superior ways to construct loops, datastructures etc, based on their lowlevel knowledge.
And I will also argue that you do not need to know anything about the compiler process itself, as long as you can predict the output on a given input.
Then you can consider the compiler as a black box... input code, compile, check, and based on the output, you change the input.
I can also argue that nobody will know EXACTLY what transformations will or will not happen, except for perhaps the compiler writers themselves.
After all, it's different for every compiler (and different versions of the same compiler), and in general this is not documented in detail, or at least, this documentation is not available to normal users.
Posted on 2004-06-03 07:30:04 by Scali
With perhaps the exception of examples where clearcode blocks are encased in macros , then used to form the body of the main sourcecode (eg z0mbie's shellcode source)...
Posted on 2004-06-06 05:30:18 by Homer
Then there are the cases where no one can force any compiler to build the code the way it needs to be! There are many instructions the compiler will not even use, or transformations outside of it's algorithms. It is like when a machine is designed to bake bread: sure you can make a sandwich with it, but it just doesn't taste the same.
Posted on 2004-06-06 12:00:45 by bitRAKE
...and in such a case, of course you wouldn't use the breadbaking machine, but some other tool more appropriate for sandwiches. "duh" :)
Posted on 2004-06-06 12:06:24 by f0dder
There are many instructions the compiler will not even use


Yes, which is a good thing. This means that these instructions can be removed from the critical path of the CPU. Only a small subset of x86 instructions are used regularly and need to be optimized.
Modern CPUs lack many instructions found in x86 altogether, and the instructions that they do have, are implemented in a way that suits the compiler better (3 operands, more registers, no complex addressing modes).
Things like inc and dec are simply superfluous when you also have add and sub. On the P4 we see that these instructions are no longer running at the same speed. Only add and sub are 0.5 clks. inc and dec are no longer used.
Posted on 2004-06-06 12:07:41 by Scali
if you weren't using masm, or you were inlining a vc6 func with __declspec (naked), you could do something like



center:
pop ecx
pop eax
sub eax,ecx
shr eax,1
ret

1 + 1 + 2 + 2 = 4 bytes


pop ecx saves 3 more bytes than mov ecx,, etc.
just some simple optimization...
Posted on 2004-06-07 00:39:33 by Drocon
The real optimization would be to inline the code, rather than doing a function call. Which is exactly what a compiler will do.
Posted on 2004-06-07 02:09:32 by Scali
center:

pop ecx
pop eax
sub eax,ecx
shr eax,1
ret


that looks like a rather special calling convention .. what do you call that?
Posted on 2004-06-07 02:12:42 by Jibz
seg fault convention? :)
Sorry, I just couldn't resist it...
Posted on 2004-06-07 03:42:55 by Starless
Drocon,
if you weren't using masm, or you were inlining a vc6 func with __declspec (naked), you could do something like
Hmm, I think you underestimate MASM, I'm positive I could use this in masm! (I know you are pro-nasm) Of course I'd have to take the default PROLOGUE off, and of course change my calling convention to ???, instead of STDCALL, which in my opinion, is a reliable default.

Side note: However, it has been shown/proven (I believe in Agner's new P4 optimization guide) that the mov version is faster, I believe the reason is that you are only modifying 1 register, instead of 2 with the push (remember ESP must change also), so (I stand under correction) the micro-operation count is smaller. Anyway, I never said anything in my post about being CPU specific, nor did I say anything about (CPU specific) speed issues, so your input is noted and appreciated!

PS: I don't believe any (good) compiler would be bad enough, when inlining to push ???, push ???, pop ecx, pop eax, unless in some insane circumstance it ran out of registers and needed to re-order registers/values (thumb sucking an idea)! Sorry!

Regards

EDIT: I'm fairly confident your code won't work, even in nasm (unless ...)?!?! At the top of the stack, is the function return address?!?!? So you'll be popping that?!?! Unless you change the calling convention, to first push the return address, then push the 2 parameters. But I still don't know a calling convention that does that? Is there one?
Posted on 2004-06-07 05:57:08 by SubEvil
Problem: I want to build a VC6 .lib, with functions exported as _name@? syntax (Isn't this supposed to be STDCALL sytax). What I'm getting now is something like ?Center@@YGHII@Z. I've tried adding _stdcall and _cdecl to my functions. I've tried changing the project settings in VC6 (from default cdecl to stdcall). I managed to get it once, but now I can't remember how :(
Posted on 2004-06-07 06:50:31 by SubEvil