|
Table of Content | Chapter Eleven (Part 7) |
|
Table of Content | Chapter Eleven (Part 7) |
Another way to pass parameters in memory is through a parameter block. A parameter block is a set of contiguous memory locations containing the parameters. To access such parameters you would pass the subroutine a pointer to the parameter block. Consider the subroutine from the previous section that adds J and K together storing the result in I; the code that passes these parameters through a parameter block might be.
Calling sequence:
ParmBlock dword I I word ? ;I J and K must appear in J word ? ; this order. K word ? . . . les bx ParmBlock call AddEm . . . AddEm proc near push ax mov ax es:2[bx] ;Get J's value add ax es:4[bx] ;Add in K's value mov es:[bx] ax ;Store result in I pop ax ret AddEm endp
Note that you must allocate the three parameters in contiguous memory locations.
This form of parameter passing works well when passing
several parameters by reference
because you can initialize pointers to the parameters
directly within the assembler. For example
suppose you wanted to create a subroutine rotate
to which you pass four parameters by reference. This routine would copy the second
parameter to the first
the third to the second
the fourth to the third
and the first to
the fourth. Any easy way to accomplish this in assembly is
; Rotate- On entry BX points at a parameter block in the data ; segment that points at four far pointers. This code ; rotates the data referenced by these pointers. Rotate proc near push es ;Need to preserve these push si ; registers push ax les si [bx+4] ;Get ptr to 2nd var mov ax es:[si] ;Get its value les si [bx] ;Get ptr to 1st var xchg ax es:[si] ;2nd->1st 1st->ax les si [bx+12] ;Get ptr to 4th var xchg ax es:[si] ;1st->4th 4th->ax les si [bx+8] ;Get ptr to 3rd var xchg ax es:[si] ;4th->3rd 3rd->ax les si [bx+4] ;Get ptr to 2nd var mov es:[si] ax ;3rd -> 2nd pop ax pop si pop es ret Rotate endp
To call this routine you pass it a pointer to a group of four far pointers in the bx register. For example suppose you wanted to rotate the first elements of four different arrays the second elements of those four arrays and the third elements of those four arrays. You could do this with the following code:
lea bx RotateGrp1 call Rotate lea bx RotateGrp2 call Rotate lea bx RotateGrp3 call Rotate . . . RotateGrp1 dword ary1[0] ary2[0] ary3[0] ary4[0] RotateGrp2 dword ary1[2] ary2[2] ary3[2] ary4[2] RotateGrp3 dword ary1[4] ary2[4] ary3[4] ary4[4]
Note that the pointer to the parameter block is itself a parameter. The examples in this section pass this pointer in the registers. However you can pass this pointer anywhere you would pass any other reference parameter - in registers in global variables on the stack in the code stream even in another parameter block! Such variations on the theme however will be left to your own imagination. As with any parameter the best place to pass a pointer to a parameter block is in the registers. This text will generally adopt that policy.
Although beginning assembly language programmers rarely use
parameter blocks
they certainly have their place. Some of the IBM PC BIOS and MS-DOS
functions use this parameter passing mechanism. Parameter blocks
since you can initialize
their values during assembly (using byte
word
etc.)
provide a
fast
efficient way to pass parameters to a procedure.
Of course
you can pass parameters by value
reference
value-returned
result
or by name in a parameter block. The following piece of code is a
modification of the Rotate procedure above where the first parameter is
passed by value (its value appears inside the parameter block)
the second is passed by
reference
the third by value-returned
and the fourth by name (there is no pass by result
since Rotate needs to read and write all values). For simplicity
this code
uses near pointers and assumes all variables appear in the data segment:
; Rotate- On entry DI points at a parameter block in the data ; segment that points at four pointers. The first is ; a value parameter the second is passed by reference ; the third is passed by value/return the fourth is ; passed by name. Rotate proc near push si ;Used to access ref parms push ax ;Temporary push bx ;Used by pass by name parm push cx ;Local copy of val/ret parm mov si [di+4] ;Get a copy of val/ret parm mov cx [si] mov ax [di] ;Get 1st (value) parm call word ptr [di+6] ;Get ptr to 4th var xchg ax [bx] ;1st->4th 4th->ax xchg ax cx ;4th->3rd 3rd->ax mov bx [di+2] ;Get adrs of 2nd (ref) parm xchg ax [bx] ;3rd->2nd 2nd->ax mov [di] ax ;2nd->1st mov bx [di+4] ;Get ptr to val/ret parm mov [bx] cx ;Save val/ret parm away. pop cx pop bx pop ax pop si ret Rotate endp
A reasonable example of a call to this routine might be:
I word 10 J word 15 K word 20 RotateBlk word 25 I J KThunk . . . lea di RotateBlk call Rotate . . . KThunk proc near lea bx K ret KThunk endp
| 11.6 Function Results |
Functions return a result
which is nothing more than a
result parameter. In assembly language
there are very few differences between a procedure
and a function. That is probably why there aren't any "func" or
"endf" directives. Functions and procedures are usually different
in HLLs
function calls appear only in expressions
subroutine calls as statements[7]. Assembly language doesn't distinguish between them.
You can return function results in the same places you pass and return parameters. Typically however a function returns only a single value (or single data structure) as the function result. The methods and locations used to return function results is the subject of the next three sections.
11.6.1 Returning Function Results in a Register
Like parameters
the 80x86's registers are the best place
to return function results. The getc routine in the UCR Standard Library is a
good example of a function that returns a value in one of the CPU's registers. It reads a
character from the keyboard and returns the ASCII code for that character in the al
register. Generally
functions return their results in the following registers:
Use First Last Bytes: al ah dl dh cl ch bl bh Words: ax dx cx si di bx Double words: dx:ax On pre-80386 eax edx ecx esi edi ebx On 80386 and later. 16-bitOffsets: bx si di dx 32-bit Offsets ebx esi edi eax ecx edx Segmented Pointers: es:di es:bx dx:ax es:si Do not use DS.
Once again
this table represents general guidelines. If
you're so inclined
you could return a double word value in (cl
dh
al
bh).
If you're returning a function result in some registers
you shouldn't save and restore
those registers. Doing so would defeat the whole purpose of the function.
11.6.2 Returning Function Results on the Stack
Another good place where you can return function results is on the stack. The idea here is to push some dummy values onto the stack to create space for the function result. The function before leaving stores its result into this location. When the function returns to the caller it pops everything off the stack except this function result. Many HLLs use this technique (although most HLLs on the IBM PC return function results in the registers). The following code sequences show how values can be returned on the stack:
function PasFunc(i j k:integer):integer; begin PasFunc := i+j+k; end; m := PasFunc(2 n l);
In assembly:
PasFunc_rtn equ 10[bp] PasFunc_i equ 8[bp] PasFunc_j equ 6[bp] PasFunc_k equ 4[bp] PasFunc proc near push bp mov bp sp push ax mov ax PasFunc_i add ax PasFunc_j add ax PasFunc_k mov PasFunc_rtn ax pop ax pop bp ret 6 PasFunc endp
Calling sequence:
push ax ;Space for function return result mov ax 2 push ax push n push l call PasFunc pop ax ;Get function return result
On an 80286 or later processor you could also use the code:
push ax ;Space for function return result push 2 push n push l call PasFunc pop ax ;Get function return result
Although the caller pushed eight bytes of data onto the stack PasFunc only removes six. The first "parameter" on the stack is the function result. The function must leave this value on the stack when it returns.
11.6.3 Returning Function Results in Memory Locations
Another reasonable place to return function results is in a known memory location. You can return function values in global variables or you can return a pointer (presumably in a register or a register pair) to a parameter block. This process is virtually identical to passing parameters to a procedure or function in global variables or via a parameter block.
Returning parameters via a pointer to a parameter block is an excellent way to return large data structures as function results. If a function returns an entire array the best way to return this array is to allocate some storage store the data into this area and leave it up to the calling routine to deallocate the storage. Most high level languages that allow you to return large data structures as function results use this technique.
Of course there is very little difference between returning a function result in memory and the pass by result parameter passing mechanism. See "Pass by Result" for more details.
A side effect is any computation or operation by a procedure that isn't the primary purpose of that procedure. For example if you elect not to preserve all affected registers within a procedure the modification of those registers is a side effect of that procedure. Side effect programming that is the practice of using a procedure's side effects is very dangerous. All too often a programmer will rely on a side effect of a procedure. Later modifications may change the side effect invalidating all code relying on that side effect. This can make your programs hard to debug and maintain. Therefore you should avoid side effect programming.
Perhaps some examples of side effect programming will help
enlighten you to the difficulties you may encounter. The following procedure zeros out an
array. For efficiency reasons
it makes the caller responsible for preserving necessary
registers. As a result
one side effect of this procedure is that the bx and cx
registers are modified. In particular
the cx register contains zero upon
return.
ClrArray proc near lea bx array mov cx 32 ClrLoop: mov word ptr [bx] 0 inc bx inc bx loop ClrLoop ret ClrArray endp
If your code expects cx to contain zero after
the execution of this subroutine
you would be relying on a side effect of the ClrArray
procedure. The main purpose behind this code is zeroing out an array
not setting the cx
register to zero. Later
if you modify the ClrArray procedure to the
following
your code that depends upon cx containing zero would no longer
work properly:
ClrArray proc near lea bx array ClrLoop: mov word ptr [bx] 0 inc bx inc bx cmp bx offset array+32 jne ClrLoop ret ClrArray endp
So how can you avoid the pitfalls of side effect programming in your procedures? By carefully structuring your code and paying close attention to exactly how your calling code and the subservient procedures interface with one another. These rules can help you avoid problems with side effect programming:
These rules like all other rules were meant to be broken. Good programming practices are often sacrificed on the altar of efficiency. There is nothing wrong with breaking these rules as often as you feel necessary. However your code will be difficult to debug and maintain if you violate these rules often. But such is the price of efficiency[8]. Until you gain enough experience to make a judicious choice about the use of side effects in your programs you should avoid them. More often than not the use of a side effect will cause more problems than it solves.
[7] "C" is an exception to this rule. C's procedures and functions are all called functions. PL/I is another exception. In PL/I they're all called procedures.
[8] This is not just a snide remark. Expert programmers who have to wring the last bit of performance out of a section of code often resort to poor programming practices in order to achieve their goals. They are prepared however to deal with the problems that are often encountered in such situations and they are a lot more careful when dealing with such code.
|
Table of Content | Chapter Eleven (Part 7) |
Chapter Eleven: Procedures and
Functions (Part 6)
27 SEP 1996
