Which calling convention do you use when you design a medium/large library in fasm, in x86 (As x64 uses fastcall anyway), but do you prefer stdcall or cdecl? And why do you prefer it?

Personally, I like cdecl because it allows you to create generalized forms of data in structures and re-use those structures across functions without fixing the stack.

For example, if most functions in a library depend on a, b, c, d, e, f, g data elements and these data elements are needed in 80% of all functions, you can just pass a pointer to that structure and never have to fix the stack when you need to call multiple functions in multiple calls. And if a function needs extra data, you can put a pointer to that extra data inside a reserved dword inside the generalized structure.

I don't know what you think about all of that, let me know your opinion. Teach me to better design functions, or let me know how you do it or prefer it.

__fastcall.

Thanks for your response, I would appreciate an explanation why you prefer one convention over the other. (Hopefully not for creating a debate or to create disagreement between different people, but to see the different perspectives from people)

Well, I write my code in FASM only, no integration with other packages.
Pushing parameters to stack seems non-Assemblery - if that is a word, probably not.
If I'll use any other convention, my code probably would be no better than C/C++ or maybe even worse.

When I say __fastcall - I do not mean standard, described in MSDN, I mean that parameters passed in registers,
can be any register.

CDECL. Because I can choose when to change ESP.

LOL!

For library public procedures STDCALL - IMO, it is more flexible than others (especially for x86!) and allows some tricks that help optimizing register use.

Sometimes for very simple and for internal use only procedures I use register parameter passing, but it has some great disadvantages.

As it's a library, it's less about preference and more about suitability. If it's aimed at HLL usage, mixing conversions can be both advantageous and detrimental, depending on the critical path. In some cases, one won't have a choice due to the target platform or other libraries enforcing the convention (thread entry points/callbacks etc).

If the library is not intended for HLLs (or just the odd top-level do-all-the-things calls), then I normally aim for "native" convention where I avoid common registers, where appropriate, and pass parameters and return values in and out of procedure-specific registers. I typically end up using r15-8 xmm15-8 etc as this avoids both general purpose instructions (think rep cmpsb etc) and calling convention collisions and therefore reduces state swapping overhead.