using __fastcall & inline at the same time

Since an inlined function isn''t actually passed any parameters (hence inline) I think __fastcall might just confuse the compiler, if do anything at all.

@Poster,
Xee said i did it . So unless he lies or does not know what he does I think your assertion that nothing can be both __fastcall and inline at the same time . K then I understand that you may mean in practice the compiler igonres one of the directives.

__fastcall and inline
Please refer to the MS Visual documentation. There nothing that prevents it and it's quite logical. For inlined functions that contain strict C/C++ code the effects of __fastcall will simply disappear in the optimization stages. But for inlined functions containing inline asm, it's another story.

@Xee
How can this happen, how can inlining slow down a function?
This may be because of register pressure. You try to tweak the compiler 3 times : once with inline (paste code here in the middle of intructions already using registers), once with fastcall (force into registers) and then with inline asm force again into registers. An Intel compatible has only 6 registers available. So sometimes using functions and call stack is better than forcing into register. Then the register cache (6*32bits) becomes the 'bottleneck'.

K Xee pls post your C code sample and the resulting asm in both cases (with or without inline keyword). Else fastcall and asm are very risky to handle. I'll explain you while and how to solve it. There is an hand made solution with __declspec. I use .6 but I don't think much has changed in .Net. I am nearly sure you'll see such stupid code in the .asm, except the wise comments :

mov eax, [esp+?] ; register memory overflowed
mov [esp+?], ebx ; ...
mov ebx, eax ; <= the fastcall stuff.
mov esi, ebx ; <= your inline asm.
; ... and the unecessary instruction list goes on.

The following sequence is due to a sequence of constraints that
starts with an instruction style __asm mov esi, param1.

In depth the problem is Visual does not recombine hand written asm instructions with C generated asm. So on the boundaries of the inlined asm function there will be a lot of sh*t because the optimizer (code scheduler) is not meant to handle this situation.

[edited by - Charles B on February 7, 2004 7:13:25 AM]

BTW I dream of an inline asm language that would be perfectly optimized ot be merged with C code. Only one more asm directive would be required. Example :

inline void Acc( register int *pOut, register int *pInp )
{
__asm reg p0, pOut
__asm reg p1, pInp
__asm reg r0 ; any available register
__asm reg r1, eax, ebx ; (r1 can be eax or ebx)
__asm mov r0, [p0]
__asm mov r1, [p1]
__asm add r0, r1
// etc ...
}

The compiler would have enough info to avoid stupid register swaps at the C/inline asm borders. It could also be cool to #pragma a directive where __asm code reordering is allowed.

Yep, gcc is great. But I also have to code my math lib for Visual.