Negative offset in structure

[nidud]

deleted

[hutch--]

I would not worry too much about FASTCALL, its always been easy enough to do your own. For those old enough to have written DLLs in Win16, you had very little stack space to play with so one of the many tricks apart from passing in registers was to have allocated a number of globals that you could write data to then call the DLL function. Worked fine and was fast enough. 

[Gunther]

I would not worry too much about FASTCALL, its always been easy enough to do your own. For those old enough to have written DLLs in Win16, you had very little stack space to play with so one of the many tricks apart from passing in registers was to have allocated a number of globals that you could write data to then call the DLL function. Worked fine and was fast enough. 

Right.  :t

Gunther

[nidud]

deleted

[jj2007]

Fastcall is an issue for compilers. In assembler, you just use the registers you like. If we were forced to adopt one here, it should be M$, because Masm32 is clearly a Windows library. But we are not forced to adopt one, and why pick a stupid one that uses ecx instead of eax, the argument returned by Windows?

[nidud]

deleted

[hutch--]

From what I can tell, the Win64 version of FASTCALL is a leftover from clapped out RISC compiler theory where some hardware had a large collection of registers to play with. It has always seemed rediculous to me that RISC theory is being taught when the majority of computers around the world are CISC and while you can waste registers in x86-64 simulating RISC, it comes at the cost of trying to make x86 like processors that are long dead.

The old STDCALL was infinitely extendable in terms of call depth being purely stack based and the only effective limit was stack memory where you run out of registers real fast with a high argument count but it also limits techniques like recursion unless you supplement the register base with stack memory. In a common algo like a quick sort, you can easily get depths of thousands and while the better designs avoid this, you just cannot write a recursive algo with registers alone.

i have tended to see Win64 as much the same mess as the old Win16, obscure and untidy function calling mechanisms, Win32 was designed by the old VAX guys and it was free of most of the Microsoft YUK but it appears that with Microsoft doing the design of what is another hybrid OS version, ( Win7 and 8 ) they have gone back to badly designed and obscure calling methods.

It will probably not be until you have a full long mode 64 bit OS version that you will have a chance to write clean code like Win32 again, do everything in 64 bit on hardware that has enough memory(Win64 does not have that yet) and you will get faster cleaner code for it. To do this well the OS will need in the future, terrabyte volumes of memory and the hardware is not yet up to this.

Think in terms of 4K video running at 60 frames a second and in the future faster again, 120 or higher and you are going to start to need far more powerful hardware than is currently available. I can run 1080 at 60 frames a second OK on my old quad (monitor does not support higher) and current video looks very good but the future is going to be much faster. By this time current 64 bit Windows will be old junk, something like all the fanfare that surrounded the introduction of the i386 so long ago.