How to - SDI
in [MFC]
|
Prev: Recommendation needed for embedded scripting solution
Next: Error C2440 cannot convert from void
From: Hector Santos on 23 Jan 2010 14:10 David, thanks for the sanity reminder. What a character! There is no win this guy! David Ching wrote: > "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message > news:#dMbF4#mKHA.5692(a)TK2MSFTNGP04.phx.gbl... >> I really really hope people take your advice with a grain of salt. >> IMO, you create more CONFUSION than not, and it has very little >> practical implication. It defies logic the comments I read here. To >> you, you probably wonder why the WORLD got to this point when it was >> DONE all wrong! > > Easy Hector, you're hot and with good reason. Joe is just being Joe. > He's actually gotten more mellow since I got here many years ago. While > his signal is very high, his noise tends to drift high too, and that's > what you're reacting to. Just remember why we're here: to help each > other and enrich the community with our experience. The effective way > of doing that is not to play Joe's game. It is to play your game. And > from what I've seen, your posts offer much good in them. Keep it up! :-) > > -- David > > -- HLS
From: Woody on 24 Jan 2010 03:21 On Jan 22, 10:32 pm, Joseph M. Newcomer <newco...(a)flounder.com> wrote: > I programmed in FORTRAN. It is a Really Bad Language, but when you need "global" > variables shared with subroutines, you have to put them in COMMON. This is no longer true. Fortran now has "modules", which can include data and subroutines. Also dynamic storage allocation, pointers and user-defined data types. And variable names can be longer than 6 characters! (FORTRAN II, anyone?)
From: David Wilkinson on 24 Jan 2010 06:21 Joseph M. Newcomer wrote: > I don't see how you can make this statement. It is most definitely NOT "Pascal" based. In > Pascal, arguments are required to be pushed left to right. __stdcall does not push > arguments left to right. Therefore, it cannot be "Pascal" based, in the sense of the > PASCAL keyword of Win16. It is complete drivel to say that __stdcall is "Pascal" based > because Pascal does not use the same linkage as __stdcall. It is true that for backward > compatibility, the obsolete macro "PASCAL" in the Windows SDK was redefined to > "__stdcall", but it does NOT mean it is a "Pascal" linkage. In fact, there is no trace of > Pascal in Win32. So I have no idea how you can use this word with a straight face and > claim it is meaningful. > > __stdcall pushes arguments right to left, and the called function removes the parameters > from the stack. That is all it means. > > "PASCAL", in Win16, means that it pushes arguments right to left and the called function > removes the parameters. Joe: I don't think you said this right. Didn't you mean __stdcall pushes arguments right to left, and the called function removes the parameters from the stack. That is all it means. "PASCAL", in Win16, means that it pushes arguments left to right and the called function removes the parameters. ? http://en.wikipedia.org/wiki/X86_calling_conventions -- David Wilkinson Visual C++ MVP
From: BobF on 24 Jan 2010 10:22 David Wilkinson wrote: > Joseph M. Newcomer wrote: >> I don't see how you can make this statement. It is most definitely NOT "Pascal" based. In >> Pascal, arguments are required to be pushed left to right. __stdcall does not push >> arguments left to right. Therefore, it cannot be "Pascal" based, in the sense of the >> PASCAL keyword of Win16. It is complete drivel to say that __stdcall is "Pascal" based >> because Pascal does not use the same linkage as __stdcall. It is true that for backward >> compatibility, the obsolete macro "PASCAL" in the Windows SDK was redefined to >> "__stdcall", but it does NOT mean it is a "Pascal" linkage. In fact, there is no trace of >> Pascal in Win32. So I have no idea how you can use this word with a straight face and >> claim it is meaningful. >> >> __stdcall pushes arguments right to left, and the called function removes the parameters >> from the stack. That is all it means. >> >> "PASCAL", in Win16, means that it pushes arguments right to left and the called function >> removes the parameters. > > Joe: > > I don't think you said this right. Didn't you mean > > __stdcall pushes arguments right to left, and the called function removes the > parameters from the stack. That is all it means. > > "PASCAL", in Win16, means that it pushes arguments left to right and the called > function removes the parameters. > > ? > > http://en.wikipedia.org/wiki/X86_calling_conventions > I caught that also. I think Joe was a little worked up and typing too fast. Niggly little details and Joe's 'charismatic' nature aside, I agree with Joe about the general concepts he's trying to get across.
From: Joseph M. Newcomer on 1 Feb 2010 09:20
See below... On Sun, 24 Jan 2010 06:21:09 -0500, David Wilkinson <no-reply(a)effisols.com> wrote: >Joseph M. Newcomer wrote: >> I don't see how you can make this statement. It is most definitely NOT "Pascal" based. In >> Pascal, arguments are required to be pushed left to right. __stdcall does not push >> arguments left to right. Therefore, it cannot be "Pascal" based, in the sense of the >> PASCAL keyword of Win16. It is complete drivel to say that __stdcall is "Pascal" based >> because Pascal does not use the same linkage as __stdcall. It is true that for backward >> compatibility, the obsolete macro "PASCAL" in the Windows SDK was redefined to >> "__stdcall", but it does NOT mean it is a "Pascal" linkage. In fact, there is no trace of >> Pascal in Win32. So I have no idea how you can use this word with a straight face and >> claim it is meaningful. >> >> __stdcall pushes arguments right to left, and the called function removes the parameters >> from the stack. That is all it means. >> >> "PASCAL", in Win16, means that it pushes arguments right to left and the called function >> removes the parameters. > >Joe: > >I don't think you said this right. Didn't you mean > >__stdcall pushes arguments right to left, and the called function removes the >parameters from the stack. That is all it means. > >"PASCAL", in Win16, means that it pushes arguments left to right and the called >function removes the parameters. **** Yes, that was clearly my error. It pushes them in the opposite direction in Win16, a source of never-ending confusion. It became particularly painful when people violated the C rules about parameter evaluation being undefined if the evaluation of one parameter could affect the evaluation of another parameter. For example, the classic failures F(a[i], ++i); This is actually *undefined* by the C language spec. But in Win16, __cdecl *most likely* would increment i first, so if the call was in the context int i = 0; F(a[i], ++i); then it would be treated as if it were F(a[1], 1); but if you changed to PASCAL, it would be evaluated as F(a[0], 1); It got even more ambiguous if you wrote i++ instead of ++i. What happened here was that programmers who needed to squeeze a little more performance out of their 20MHz 386 would switch calling conventions, and then spend days or weeks finding all the bugs that fell out because of (a) they violated the language specification and (b) they had just discovered what "undefined" meant as a consequence of (a). It got even messier when you had to call assembly-language functions, which were often required back then, usually for low-level interfacing. So when Win32 was designed in the late 1980s, the decision was made to rationalize the parameter passing mechanism and decouple the parameter order from the cleanup. If you haven't looked at Win64, it uses a 4-register __fastcall for EVERYTHING, and concepts like __stdcall and __cdecl are considered "noise" words, just like "FAR" is now, maintained for backward compatibility with older operating environments. And in fact parameters are *not* pushed onto the stack; instead, the caller allocates a stack frame large enough to hold the longest parameter sequence, and the stack does not move up and down during function execution (this does wonders for keeping speculative execution pipes happy!) so variable-length parameter lists are straightforward. The called function does not "clean up" the stack at all; the stack is not modified. This also eliminates the need for the EBP frame pointer register, because ESP is now stable throughout the called function, freeing up another computational register. THat said, if a function is static, I've seen the compiler *invent* a specific register calling convention for it. I've seen the compiler shove a couple values in a register, and do a JMP to the function, because it drops a RET->RET sequence that would otherwise exist, e.g., instead of push p1 push p2 call f ret we see the values being developed in registers, e.g., imul eax, 17 add ecx, 14 jmp f and instead of f expecting parameters in ecx and edx, it finds them in eax and ecx. And with Link-Time-Code-Generation in either win32 or win64, the code that is executing often does not resemble the code in the generated compiler listing! joe > >? > >http://en.wikipedia.org/wiki/X86_calling_conventions Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |