Valhalla Legends Archive

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

Quote from: iago on March 01, 2004, 08:37 AM


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

How else would you explain the GUI?

Quote from: Raven on March 01, 2004, 09:45 AM

Quote from: iago on March 01, 2004, 08:37 AM


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

How else would you explain the GUI?

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.

Now Windows is written in PASCAL?

Quote from: Grok on March 03, 2004, 09:16 AM
Now Windows is written in PASCAL?

That's probably the only language Amend knows

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

Quote from: Grok on March 03, 2004, 09:16 AMNow Windows is written in PASCAL?

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

Quote from: Kp on March 03, 2004, 06:14 PM

Quote from: Grok on March 03, 2004, 09:16 AMNow Windows is written in PASCAL?

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

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 from: iago on March 03, 2004, 08:51 PM

Quote from: Kp on March 03, 2004, 06:14 PM

Quote from: Grok on March 03, 2004, 09:16 AMNow Windows is written in PASCAL?

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

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?

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 from: Kp on March 03, 2004, 06:14 PM
Well, that would explain the horrible calling convention.  cdecl is a much better calling convention IMO.

Why?

Quote from: Adron on March 04, 2004, 03:12 AM

Quote from: Kp on March 03, 2004, 06:14 PMWell, that would explain the horrible calling convention.  cdecl is a much better calling convention IMO.

Why?

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:


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


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.