Parameter Passing: Difference between revisions

Certain commands such as <code>INC</code>,<code>DEC</code>,<code>ASL</code>,<code>LSR</code>,<code>ROL</code>, and <code>ROR</code> inherently alter the memory address that is used as an argument. Thus their use on a memory address is pass-by-reference.

 

 

However, opcodes that use a register as their primary operand are strictly pass-by-value.

 

;If the carry was set prior to this operation, also add an additional 1 to the accumulator.

 

 

LDA $40 ;load the value stored at memory address $40 into the accumulator

 

The main takeaway from this is that by default, the use of <code>LDA/LDX/LDY</code> commands to load from memory is pass-by-value. In order to actually update the memory location, you must store the value back into the source memory address.

Generally, parameters are either passed using the stack or with temporary zero-page memory addresses. While these are both forms of memory that are getting overwritten, the actual sources of the data remain the same.

=====Example of in (immutable)=====

jsr MultiplyBy4

 

lsr A

lsr A

=====Example of out (result)=====

This routine reads the joystick output on Commodore 64 and stores it in the output variable <code>joystick1</code>.

lda $DC00

ora #%11100000

sta joystick1

=====Example of in/out (mutable)=====

This one's tricky because of the way pointers work on the 6502. Unlike the other architectures of its day there are no "address registers" per se, but we can make our own using the zero page.

 

LDA #$03 ;load the low byte of the parameter's address

STA $20 ;store it in the low byte of our pointer variable.

adc #$20 ; 0x20 = decimal 32

sta ($20),y ; overwrite the old value stored in $0003 with the new one.

 

===Example [[68000 Assembly]]===

Parameters are typically passed via the stack or through registers. For human-written assembly, the programmer can pass an argument by reference by passing a pointer to the argument rather than the argument itself. Of course, the function will need to dereference that pointer; however whether the function writes back the new value to that memory address is also decided by the programmer. This means that just because a parameter is passed by reference does not mean that it gets altered by the function that received it. This (contrived) example shows this concept in action.

 

MOVE.L #$00FF0000,D0 ;load D0 with the pointer 0x00FF0000 (I decided this was a pointer just for example's sake.)

MOVE.L D0,-(SP) ;push that value onto the stack.

MOVE.L (A0),D1 ;dereference the pointer (we're treating it as a pointer to an int)

ADD.L D1,D0 ;add the values.

 

===Example [[Ada]]===

 

Early versions of the ARM were unable to directly operate on memory without loading the value into a register first. So almost all commands were inherently pass-by-value unless they explicitly stored an updated value in the same memory location.

mov r0,#memoryAddress ;r0 contains the memory address, not the value stored within.

mov r1,#anotherMemoryAddress ;r1 contains the memory address, not the value stored within.

mov r2,#memoryAddress ;load the MEMORY ADDRESS into r2

add r0,r0,r1 ;add r1 to r0 and store the result in r0

 

Typically when talking about pass-by-value or pass-by-reference, a programmer is referring to the contents of a memory address. The stack and the CPU's data registers are not included in the conversation. It's expected that a data register gets "clobbered," after all, it's impossible to do actual math otherwise. Or so you might think, but the ARM takes the concept of "pass-by-value" one step further. The data registers themselves can be operated on in some ways without altering their contents:

* In any operation, the contents of a data register can be bit-shifted or bit-rotated just for that operation, and the actual value is unchanged.

[[x86 Assembly]] can do neither of the above; at least one of its registers used as an operand must be the destination for the result.

 

===Example [[C]]/[[C++]]===

 

===Example [[Fortran]]===

 

 

Trying to modify an argument with ''intent in'' triggers an error at compile time.