From: Hector Santos on
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
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
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
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
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