What are the negative aspects of using __fastcall function-calls (i.e. passing parameters directly into the registers, instead of pushing them on the stack)? I mean, there must be _something_ negative about it, otherwise all function-calls should be done like this. Best regards, Henrik

Some compilers have poor/different support for it.
I believe the Borland compiler pushes three parameters into the stack and VC++ only two.
Plus it does not work on functions with a variable argument list.

There is a little tutorial on this at: http://www.amadev.net/amadev/speedart.htm (which I wrote BTW )

interpobility is lacking

_cdecl & _stdcall work pretty much the same on all compilers in all procedural rooted languages, _fastcall is compiler dependant ...soooo you can''t use fastcalls in .dlls for instance.
(Well you could but it''d be a bad idea)


Magmai Kai Holmlor
- The disgruntled & disillusioned

I think it is also bad to use inline assembly in a function that uses the
__fastcall keyword, since the passed parameters are already being used in
the registers. Although, I have never tested this case myself, so I don''t
know for sure.

__fastcall is only for Intel machines.

Yes, these are all good points, but if I''m ONLY using MSVC, then there''s no real reason why I shouldn''t use __fastcall (if it''s not a dll of course)? Even if MSVC only passes three parameters directly into the registers (I assume it''s the three first, everything seems to be done in order in MSVC), wouldn''t this still be a speed gain, since the parameters at some point (if I want to modify them) have to end up in the registers anyway? That __fastcall only works on Intel processors is quite alarming, though! :-/

Countach, I read your article and compared it to an article I saw on Dr. Dobbs homepage ("Winning the Passing Game", http://www.ddj.com/columns/optimize/2001/0101om/0101om002.htm). There the author claims, and i quote, that:

"Looking at the design of modern CPUs it is easy to see that inlining does not provide any performance improvement. In most cases, call and ret instructions are processed in zero cycles due to successful static branch prediction and instruction prefetching."

From reading that article it basically seems that __fastcall is the way to go, and that inlining is totally worthless.

Best regards,
Henrik

I think they mean that __fastcall works only on x86 CPUs, which means AMD, Intel, Cyrix, IDT, etc. will run your code just fine.

quote:

---

Original post by null_pointer
I think they mean that __fastcall works only on x86 CPUs, which means AMD, Intel, Cyrix, IDT, etc. will run your code just fine.

---

Yes.. that''s what I meant.. Intelx86 chipsets,

Sorry for the confusion.

quote:

---

Even if MSVC only passes three parameters directly into the registers (I assume it''s the three first, everything seems to be done in order in MSVC), wouldn''t this still be a speed gain, since the parameters at some point (if I want to modify them) have to end up in the registers anyway?

---

No, because you won''t neccessarily need them in the registers at the same time. The x86 arch. is RISC based, so-far-as only certain registers can be used for certain op codes. ie CX *must* be used for looping. AX(:BX) *must* be used for math ops. Sooo, if you do a fastcall, and fill ax, bx, & cx, now it needs to push those regs before it can run your code, so it may not save you anything.

And inlining can save you something, if the code actual does get inlined, then instead of prefetching calls & rets, it''ll pipeline the loop.

Magmai Kai Holmlor
- The disgruntled & disillusioned

Ok, but I keep seeing warnings about avoiding excessive use of inlining since it can blow some buffer. Shouldn''t this be a result of just writing very large functions as well? I know that you just should inline small and compact functions, but what rule of thumb is there regarding the size of a function as a candidate for inlining?

I really appreciate you guys answering my questions! Thank you! :-P

Best regards,
Henrik