Common x86 Calling Conventions | Hacker News Reader

Common x86 Calling Conventions

jlospinoso.github.io

27 pointsmirceasoaica15 comments

Title should be "Microsoft x86 Calling Conventions". The whole article is based on Microsoft-specific conventions and tools.

When I saw the following, I stopped reading:

  MultiplyEaxByTwo:
  shl eax,2
  ret

"shl eax, 2" means bit shift left eax by two, or "eax << 2". Also, while the end result is same as with "shl" [1], "sal" [2] should be used for idiomatic [3] assembler:

Fixed:

  CorrectMultiplyEaxByTwo:
  sal eax, 1
  ret

[1]: "shl", shift logical left

[2]: "sal", shift arithmetic left

[3]: http://en.wikibooks.org/wiki/X86_Assembly/Shift_and_Rotate#A...

And 32 bit only. It doesn't cover the 64bit conventions which deviates more wildly on Win64 from the common amd64 ABI.

Talking about 64b, does anyone know why MS decided not to go with the AMD64 abi? Is it because they had their own 64bit CC for e.g. itanium and kept that?

Looks like they went with extending their existing __fastcall calling convention. http://blogs.msdn.com/b/oldnewthing/archive/2004/01/02/47184...

The biggest surprise going to 64bit is probably the stack redzone. It's bitten the linux kernel a few times too, I think.

sar/sal is for signed numbers, shr/shl is for unsigned numbers. Which one you want depends on the types you are working on.

Also, "sal" and "shl" perform the exact same operation with the exact same side-effects. Some sources seem to hint that "sal" is the one going out of fashion - https://code.google.com/p/corkami/wiki/x86oddities#sal and http://stackoverflow.com/a/8373438/2412419

Oh, I thought SAL only existed as a mnemonic, I was rather surprised to find out SAL actually has x86 instruction encoding different from SHL!

It's an undocumented one, that just happens to fill the encoding space of:

    - shift right and insert 0 ("logical right")
    - shift right and insert sign bit ("arithmetic right")
    - shift left and insert 0 ("logical left")
    - shift left and insert... 0 ("arithmetic left") **

My guess is that it causes the hardware to attempt to sign-extend and shift left, but the latter means the former doesn't have any effect.

The Z80 has a similar gap in the encoding but rather more unusual undocumented behaviour here, where it would shift left and insert a 1 in the lowest bit.

Well, cdecl is used by GCC too.

It also mentions very little (i.e. not at all) about callee/caller-saved registers, which is a very important part of a calling convention.

There's another "WTF" moment in the code too:

    xor eax,eax
    add eax,[esp+4]
    add eax,[esp+8]
    add eax,[esp+12]

I was somewhat confused at the diagrams with "low memory" at the top and "high memory" at the bottom...

Not like Windows isn't common, though ;)

Can you introduce good books about these topics?(linker,loader,calling conventions ,dynamic linking etc).I am looking for good book for deeply understanding these topics(given that traditional OS books just talks about theory)

I can't comment on its "goodness" but the textbook that sprang to mind is Linkers and Loaders: http://www.amazon.com/Linkers-Kaufmann-Software-Engineering-...

The bad news is that it's from '99 but, as far as the foundations go, I can't imagine linkers back then were that different.

Thank god for x64 that got rid of this unnecessary cruft.

A wild __vectorcall appeared!

http://blogs.msdn.com/b/vcblog/archive/2013/07/12/introducin...

https://msdn.microsoft.com/en-us/library/dn375768.aspx

It is my understanding that the cruft is microsoft-specific: other systems use cdecl, fastcall and stdcall are related to Windows APIs and techs. And even though AMD published a call convention as part of AMD64, Microsoft ignored it in favour of their own fastcall-derived CC[0], and have added a new one since (vectorcall[1])

[0] https://msdn.microsoft.com/en-us/library/ms235286.aspx

[1] https://msdn.microsoft.com/en-us/library/dn375768.aspx

Reply on news.ycombinator.com