OSDev.org

Hi

What is the best way of passing parameters to procedures (not macros) in NASM?

Thanks
Steven Graham

C compilers often pass parameters on the stack. Also local variables exist on the stack. Both of these make sense because this is partly how the "scope" of data is established.

However, in assembly the convention tends to be a bit different. Data is passed through the registers, and it is the responsiblity of the called routine to push/pop the registers so it doesn't destroy their original state. Usually it is AX or DX for passing values (for no specifically technical reason that I'm aware of; rather this is within the convention of how the registers are typically used). SI is often used for strings.

I'm sure that one of the reasons that assembly coders tend not to use the stack is that it is gruesome to try to follow code that does this. Register passing (and a short comment) makes for good readability.

Macros for passing parameters is really just a way to make the call look more like C. However, it is still handled through the registers.

ic......

"and it is the responsiblity of the called routine to push/pop the registers so it doesn't destroy their original state"

Surely this does not matter so much with the registers that carry the parameters for the routine?

Also, what about functions? Surely they have to leave their result in a register?

Also, what if there are more parameters than registers?

Finally, how do I do local variables in assembly?

Thanks
Steven Graham

Any registers that need the same values after the routine as before have to be saved on the stack. PUSHA/POPA simplifies this. You especially have to be careful of cases where these are "hidden", as in complex string instuctions. But yes, if you are changing it in the routine, you don't need to save it.

It is unusual for a routine to be called simply to set the values of the registers to be used after the routine has returned. This probably introduces a readability problem, as well as a potential for bugs. More commonly, variables will be changed.

More parameters than registers? On a Intel chip, you might want to rethink the design because this is surely to become problematic.

I can see where you are coming from .... rewriting C functions in assembly. I think it is best to be clear on the problem and solve it in assembly, and forget about what it looks like in C. You could end up with a lot of clutter, and the goal is to be as clear, lean, and mean as possible. Economical without being obtuse.

In assembly, a routine should be called when a bit of code is used repeatedly. While this is true in C as well, it is typically also used to clarify the structure (and abstractions), so one-time uses of functions are common. This kind of thing is unneccesary in assembly IMO.

crazybuddha wrote:In assembly, a routine should be called when a bit of code is used repeatedly. While this is true in C as well, it is typically also used to clarify the structure (and abstractions), so one-time uses of functions are common. This kind of thing is unneccesary in assembly IMO.

It occurs to me that, even if one were to use that sort of top-down approach in assembly, many cases would be better solved with macros rather than full functions. There's a long history of using macro assemblers as a sort of pocket compiler, using macros for the vast majority of the code (the original SNOBOL interpreter comes to mind, historically).

Still, this is quite a different viewpoint than that of conventional assembly programming, at least as different as that of 'high level assemblers' such as TERSE. It is mostly a matter of stylistic preference, but there are other concerns as well. The costs of the higher degree of abstraction, while less than in a true HLL, is still there, and is not always appropriate for assembly code to be so highly abstracted. In the end, it largely depends on what your goal is.

hmm Interesting

Personally, by background is Borland Turbo Pascal and Delphi rather than C (I find C's syntax too messy for my liking) but just like what you said, in my lessons at college (I allready knew pascal by then though) the teacher stressed that it was best programming practice to write all your code in the procedures and then call the procedures one by one, a real top down approach, you saying that it is different in asm, only use them if you need code reuse, ok.

I remember one teacher at college saying that programming is a way of thinking (he programs in Visual Basic), I guess that assembly programming is a different way of thinking to that of a HLL programmer.

Are there any sites on the net I can go to that will show me all the differences between the appraches between HLL and assembly language programmers (such as asm programmers using the registers rather than the stack).

I think the BIOS routines are a good examples of register based parameters.

When it comes to local variables, should I just use the stack, or is there a better way that an asm programmer can do it.

Thanks
Steven Graham

srg wrote: hmm Interesting

I remember one teacher at college saying that programming is a way of thinking (he programs in Visual Basic), I guess that assembly programming is a different way of thinking to that of a HLL programmer.

Comparing VB and Asm ... well . The way-of-thinking is *completely* different. You can't open an editor and say : "hmmm ... i'm going to compute x?+y? and see if it match z? ...".
In asm, you must think-out and plan everything before writing the first line of code (imho)... first draw some structurograms, organigrams, etc. then define datas you'll need and only then write code that performs what you need...

When it comes to local variables, should I just use the stack, or is there a better way that an asm programmer can do it.

Yes. The assembler coder can do much better than [ebp+8] for its local variable: if the program locallity is well-known, he can use just registers and thus limitting the access to memory. When some computations results is needed in a long future, he can just push values and pop them later (using the stack in its LIFO mode rather than in random-access memory)

Now, with caching of the top-of-stack and pipelining, all these techniques don't really improve the speed, but mainly the code size...

he can use just registers and thus limitting the access to memory

Now I'm really starting to see why x86 does not have many registers at all!! Using them for local variables as well.

Steven Graham

srg wrote: you saying that it is different in asm, only use them if you need code reuse, ok.

I exagerrated a bit. In longer programs, it is helpful to impose some modularity. I sometimes see short programs in which routines are called for no apparent reason.

That must slow a short program down as well?

I'm more concerned with slowing ME down while I try to read through the code, trying to understand it.