[img]http://images.ucomics.com/comics/ft/2004/ft040301.gif[/img]

I didn't know Windows was programmed in a basic-style language :(

[quote author=iago link=board=2;threadid=5526;start=0#msg46903 date=1078151834]


I didn't know Windows was programmed in a basic-style language :(
[/quote]


How else would you explain the GUI? ;)

[quote author=Raven link=board=2;threadid=5526;start=0#msg46909 date=1078155942]
[quote author=iago link=board=2;threadid=5526;start=0#msg46903 date=1078151834]


I didn't know Windows was programmed in a basic-style language :(
[/quote]


How else would you explain the GUI? ;)

[/quote]

Yes, it's interesting how KDE went to such great lengths to mimic its looks functionality...

[edit]I am a firm KDE supporter. :) [/edit]

Same, There was a breif while I would use Gnome but... KDE grew up and I think its undisputed now for nice linux desktops.

[img]http://images.ucomics.com/comics/ft/2004/ft040303.gif[/img]

Now Windows is written in PASCAL?

[quote author=Grok link=board=2;threadid=5526;start=0#msg47231 date=1078327002]
Now Windows is written in PASCAL?
[/quote]

That's probably the only language Amend knows :)

Makes sense since Pascal was used a lot for learning programming before.

[quote author=Grok link=board=2;threadid=5526;start=0#msg47231 date=1078327002]Now Windows is written in PASCAL?[/quote]

Well, that would explain the horrible calling convention. cdecl is a much better calling convention IMO.

[quote author=Kp link=board=2;threadid=5526;start=0#msg47332 date=1078359267]
[quote author=Grok link=board=2;threadid=5526;start=0#msg47231 date=1078327002]Now Windows is written in PASCAL?[/quote]

Well, that would explain the horrible calling convention. cdecl is a much better calling convention IMO.
[/quote]

As opposed to stdcall or fastcall or what? It seems to me that fastcall is the best in terms of speed and clarity, especially for 1 and 2 parameters.

[edit] incidentally, what's thiscall mean?

[quote author=iago link=board=2;threadid=5526;start=0#msg47369 date=1078368713]
[quote author=Kp link=board=2;threadid=5526;start=0#msg47332 date=1078359267]
[quote author=Grok link=board=2;threadid=5526;start=0#msg47231 date=1078327002]Now Windows is written in PASCAL?[/quote]

Well, that would explain the horrible calling convention. cdecl is a much better calling convention IMO.
[/quote]

As opposed to stdcall or fastcall or what? It seems to me that fastcall is the best in terms of speed and clarity, especially for 1 and 2 parameters.

[edit] incidentally, what's thiscall mean?
[/quote]I believe thiscall is used in for classes/member functions, where the this pointer is mov'd into ecx, or pushed on the stack or something. I this it's mov'd into ecx on MS compilers.

thiscall is a modifier to whatever calling convention you select (cdecl, fastcall, stdcall, etc). It changes based on that.

[quote author=Kp link=board=2;threadid=5526;start=0#msg47332 date=1078359267]
Well, that would explain the horrible calling convention. cdecl is a much better calling convention IMO.
[/quote]

Why?

[quote author=Adron link=board=2;threadid=5526;start=0#msg47399 date=1078391530][quote author=Kp link=board=2;threadid=5526;start=0#msg47332 date=1078359267]Well, that would explain the horrible calling convention. cdecl is a much better calling convention IMO.[/quote]Why?[/quote]

Check out the code recent gcc builds do when set to optimize heavily for speed. Instead of only allocating space for automatics on the stack, it allocates space for automatics + room for all the parameters of the most argument-heavy subroutine called. For instance, CreateFile takes 7 parameters, so it allocates 4*7 extra bytes. It then uses mov to initialize those fields as the results are computed; the advantage is that you can remove ordering dependencies by doing so. However, when using _stdcall, the compiler must fix the stack after each call is completed because the callee has erased the argument-window the compiler created.

iago: I should have clarified. I was only coming down on _stdcall in particular as being inferior to _cdecl. _fastcall (and more properly, regparm(3), which is superior to _fastcall) are both good calling conventions in certain cases. However, for functions which do a great deal of initialization-type work before using their parameters, _fastcall is a bad choice since those values must be moved out to the stack to preserve them during initialization. It's a very situation-dependent decision.

I'm not convinced that that is enough to help much. With stdcall, the stack reset is done by the return statement. With cdecl, the compiler has to emit code to do that. Yes, you may avoid doing it more than once per subroutine, but still...

Look at calling funcA(funcB(0, 1), 0, funcC(3, funcE(7), 1), 0, funcD()) by:

[code]
xor ebx, ebx
call funcD
push eax
push 7
push 1
call funcE
push eax
push 3
call funcC
push ebx
push eax
push 1
push ebx
call funcB
push eax
push ebx
[/code]

I believe in many cases the code to set up a stack frame is smaller if you don't sub esp by some amount first. Any arguments you like to pass from registers are stored with a single byte instruction push, while storing a register to an offset from esp requires a multi-byte instruction.

Code that stores into a fixed stack frame will be bigger, and then most likely slower, or more likely to fill the processor's cache.

[quote author=Adron link=board=2;threadid=5526;start=0#msg47486 date=1078441169]
I'm not convinced that that is enough to help much. With stdcall, the stack reset is done by the return statement. With cdecl, the compiler has to emit code to do that. Yes, you may avoid doing it more than once per subroutine, but still...

I believe in many cases the code to set up a stack frame is smaller if you don't sub esp by some amount first. Any arguments you like to pass from registers are stored with a single byte instruction push, while storing a register to an offset from esp requires a multi-byte instruction.

Code that stores into a fixed stack frame will be bigger, and then most likely slower, or more likely to fill the processor's cache.[/quote]

I don't contest the size by any means. The optimization level I was thinking of (-O3) prefers speed over all else; you can get smaller code just by backing off to -O2 (or if you want minimal code space usage, -Os). I hadn't considered the cache issue, but I expect that the cache is big enough to tolerate a few dozen parameters. It's my understanding from the gcc documentation that the intended performance gain was that the change will remove the sequence dependency of the parameters, with the hope that the compiler can generate better code if it can prepare the parameters in whatever order it pleases.

As a closing point, I'd like to say _stdcall is also bad because it allows VB code to work when calling WinAPI functions. ;)

I suppose lifting the sequence dependency might improve performance in some cases, but I don't think it will do that in most, or even in a large number of cases.

Also, keeping most of the calls as small as possible using only simple pushes, and adding a "sub esp, X" for the cases where setting up a stack frame in a random order would be advantageous might still result in faster code.

MSVC++ seems to use pushes to store data on stack sometimes, and subtractions from esp sometime. Most of the time it uses pushes.

I believe the cache issue is an important one. Not for applications that run alone in the system and have the cpu to themselves, but for most real-world applications minimizing size is important for performance. Either you're small, or you're pushed out of cache on a task-switch, or even swapped out.

Have you seen the result of post-processing tools that move seldom used code to completely different memory pages? That doesn't seem to save a large percentage, but it's still done - I doubt it would be done if it improved nothing since it's an inconvenience and makes debugging ewwy.

Anyway, I suppose some benchmarking of large applications compiled with either setting might be the best test :)

[img]http://images.ucomics.com/comics/ft/2004/ft040304.gif[/img]


[img]http://images.ucomics.com/comics/ft/2004/ft040305.gif[/img]