OSDev.org

smwikipedia wrote:Now I found that the mix of the above 3 manners is making things complicated. And I always fall into the situation where I have to scratch my head to make sure whether certain register is polluted. So I decide to pass the parameters only through stack. And use the following function template as a lazy once-for-all solution:

Hobbes wrote:This will trash your stack and return to wherever:

Code: Select all

    addl    yyy, %esp
    ret

This is how stdcall does it:

Code: Select all

    ret     yyy

This is a stack thrasher too:

Code: Select all

    pushal
    subl    xxx, %esp
    ....
    popal

Brendan wrote:Hi,

smwikipedia wrote:Now I found that the mix of the above 3 manners is making things complicated. And I always fall into the situation where I have to scratch my head to make sure whether certain register is polluted. So I decide to pass the parameters only through stack. And use the following function template as a lazy once-for-all solution:

In general, people who are used to one language that learn a different language tend to try to do things the same way they did in the first language, even when it's not really appropriate for the second language. An example of this is a C programmer who learns C++ (and doesn't use many of the OOP features of C++), or a C programmer who learns Python (and keeps putting semicolons at the end of statements), or a C programmer that learns assembly (and continues thinking that using the stack for passing parameters and/or only returning a maximum of one value from a routine is sane).


Cheers,

Brendan

smwikipedia wrote:Thanks Brendan for your comment.
I am still a newbie. Could you tell me what's on your mind when you see my code? It seems I missed something...

• you rarely need to pass more arguments than there are registers. If this is the case you've probably failed to split code up into routines of manageable size (e.g. you've got a massive routine that does "everything" rather than a set of routines), or you should be using a pointer to a structure instead.
• you rarely need to allocate space for local variables on the stack. Again, split code up into routines of manageable size. There are rare cases where local variables can't be avoided (for some reason, graphics code seems to be the main culprit); but it's easy enough to handle these rare cases manually (e.g. "sub esp,8", "%define myFirstVar [esp]", "%define mySecondVar [esp+4], etc").
• use EBP as just another general register (it helps to avoid the need for local variables). You can use it for input and output parameters too. There's no need to use it for a stack frame pointer.
• don't forget that you can use flags as output parameters. This avoids the need for the caller to test the result (for example, "call foo" then "jc .failed" is more efficient than "call foo", "test eax,eax", "jne .failed").
• you rarely (never) need to pass a variable number of arguments. For example, the actual code for something like "printf()" is ugly and inefficient (it only exists for convenience) - consider separate routines to print a character, print a string, print a value in hex, print a value in decimal, etc so you don't have to waste CPU time by parsing a format string (and don't have to bother with variable arguments).
• if the output of one routine may be used as the input to another routine, try to make the output match the input. For example, imagine you've already got a routine named "get_colour" that returns "red" in EAX, "green" in EBX and "blue" in ECX; and you're writing a routine named "combine_colour" to combine separate red/green/blue values into a single integer (maybe for 16-bpp). In this case, the registers used should match, so people can do "call get_colour" then "call combine_colour" with no instructions inbetween at all.
• for registers that are trashed (e.g. used for local variables), in general it's more efficient (for space) for the routine to save/restore them than to expect every caller to save/restore them. It also makes it easier to maintain the code if you know that you can call any routine and the only registers that will be modified are registers used for outputs (otherwise, changing a routine so it uses an extra register would mean finding every place where the routine is called). You'll also probably find situations where a register is only used sometimes (e.g. a conditional branch might cause the CPU to skip a block of code that uses the register). In this case you can optimise a little (e.g. avoid saving/restoring the register when it's not used).

;Move pages from one virtual address to another
;
;Input
; ecx		Number of pages to move
; edx		Virtual address to put first page moved
; esi		Virtual address of first page to move
;
;Output
; carry	Set if not enough memory error

MEM_movePages:
     ;**stuff**
     ret

smwikipedia wrote:Hi geeks~

I am developing some functions in assembly language, at the beginning, my functions passing the parameters in the following 3 manners:

- registers
- global data in .data section
- stack

Now I found that the mix of the above 3 manners is making things complicated. And I always fall into the situation where I have to scratch my head to make sure whether certain register is polluted. So I decide to pass the parameters only through stack. And use the following function template as a lazy once-for-all solution:

Code: Select all

  pushl %ebp
  movl %esp, %ebp
  pushal          <--- save all the registers, this is kind of a lazy solution
  subl xxx, %esp  <--- allocate space for local variables
  ....(function body)      
  popal           <--- restore all the registers
  movl %ebp, %esp
  popl %ebp
  (addl yyy, %esp)<--- if it is __stdcall convention, the callee will clear the stack
  ret

(xxx is the size of local variables for callee, yyy is the size of paramters pushed by caller.)

The caller is responsible for push parameters and clear the stack (like the C call convention). Of course, if the number of parameters is fixed, I can make the callee to clear the stack (like the __stdcall convention on Windows).

I am hoping this template could relieve me from the confusions of registers usage. Could it achieve that? If it is low efficiency, is there some better approach? I'd like to hear your comment.

Many thanks.

  pushl %ebp
  movl %esp, %ebp
  pushal          <--- save all the registers, this is kind of a lazy solution
  subl xxx, %esp  <--- allocate space for local variables
  ....    
  addl xxx, %esp  <--- reclaim the space for local variables
  popal           <--- restore all the registers
  movl %ebp, %esp
  popl %ebp
  ret yyy     <--- for __stdcall convention, the callee will clear the parameters pushed on stack by caller

Brendan wrote:Hi again!

One last thing I forgot.

If you need to call a routine written in assembly from C; then create a wrapper (e.g. in header file) that uses inline assembly to call your routine (instead of writing the routine to use C calling conventions). This gives the compiler the freedom to optimise register usage (and avoids the need to pollute the assembly routine).


Cheers,

Brendan

Brendan wrote:

• if the output of one routine may be used as the input to another routine, try to make the output match the input. For example, imagine you've already got a routine named "get_colour" that returns "red" in EAX, "green" in EBX and "blue" in ECX; and you're writing a routine named "combine_colour" to combine separate red/green/blue values into a single integer (maybe for 16-bpp). In this case, the registers used should match, so people can do "call get_colour" then "call combine_colour" with no instructions inbetween at all.

a5498828 wrote:you cant just add/sub esp.
stack has fixed size, and it can expand it by using guard pages. if you substract too much, you will skip guard page overwriting another data or code.
use enter instruction, wich is safe.