Return values and parametery in assembly

I‘ve never had a problem with assembly itself. My only problem is that I dont understand how arguments are passed in functions and how they are returned.

Let‘s say

PUBLIC AddNumber
AddNumber PROC
   MOV RAX, RCX
   ADD RAX, RDX
   RET
AddNumber ENDP
END

I understand that the first 2 params are passed to ecx and edx but what is ebx for? If I invoke an official microsofz function like KeRaiseIrqlToDpcLevel will it return the KIRQL to RAX aswell?

The way to call a function, including argument passing and return values, depends on each systems calling convention.

This is called a convention because, when you’re both the author and caller of a function, you can do whatever works with the instruction set at hand.

In other words, if your function looks at stack for parameters, and the calling function puts them there, things generally work fine.

However, if this isn’t the convention on your target system, this causes issues. Some notable ones are:

• tooling like debuggers will give incorrect results when asked “what is the value of parameter X to this function?”
• people using your code will likely assume you’re using the convention, and be confused as to why it doesn’t work.
• you end up with errors such as memory leaks if you mix up caller / caller cleanup.
• if you’re not the author of the function, like with KeRaiseIrqlToDpcLevel, you need to know their convention to use it.

This are some of the reasons why people often stick to the calling convention of a particular system.

Given you’re talking about RAX and you’re talking about Windows functions, I presume you’re building for an x86_64 Windows system. That would make this page relevant to you:

A scalar return value that can fit into 64 bits, including the __m64 type, is returned through RAX. Non-scalar types including floats, doubles, and vector types such as __m128, __m128i, __m128d are returned in XMM0. The state of unused bits in the value returned in RAX or XMM0 is undefined.

• Microsoft x64 calling convention

I am guessing that KIRQL is some kind of integer type <= 8 bytes in size, so I would expect it to be in the RAX register by convention, yes.