Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uwm.edu!bionet!agate!ucbvax!ucsd!ucrmath!musial!rhyde
From: rhyde@musial.ucr.edu (randy hyde)
Newsgroups: comp.sys.apple2
Subject: Re: ML subroutines (passing parameters in ML)
Message-ID: <13845@ucrmath.ucr.edu>
Date: 24 Apr 91 16:56:57 GMT
References: <3397@kluge.fiu.edu>
Sender: news@ucrmath.ucr.edu
Reply-To: rhyde@musial.ucr.edu (randy hyde)
Lines: 51

There are many different ways to pass parameters in assembly language.

1) Use the registers.  This is the fastest, shortest, and easiest way to
do it.  For many years you could guarantee that your assembly language
programs ran *much* faster than C by passing parameters in the
registers.  Today, C compilers have wised up and *they've* started
passing parameters in the registers as well.

2) Pass parameters in global (esp direct page on 65xxx) memory
locations.  From a software engineering point of view, one might claim
that using global variables is bad, but if the variables are used only
for these particular parameters, there won't be a problem.  Set up is a
little more tedious and time consuming than registers, but still really
fast.  Note that this technique gets really sticky and inefficient if
your code must be reentrant.

3) Pass parameters in the code stream.  This works really great for
constant parameters (including addresses of variables).  For example, I
have a printf routine you call as follows:

		jsr	printf
		byt	"This is a test of printf,  i=%d, ch=%c\n",0
		adr	i,ch

In this example I've passed the parameters to printf as bytes
immediately following the jsr.  The printf routine pops the return
address which points at the beginning of the parameters.  This is a
convenient and fast way to pass data, but it only works for parameters
which never change (note, however, that the values of I and CH above
could change, but they're not the real parameters here, the addresses of
I and CH are the parameters and they don't change.)  I am assuming here,
of course, that self-modifying code is unacceptable to you.  If you want
to use self-modifying code, you can modify the parameter lists following
the call.  Not recommeded though.

4) Pass parameters on the stack.  This is how most HLLs pass parameters.
It is slow, big, and accessing the parameters is inconvenient,
especially on processors like the 65816 which don't have a frame pointer
register.  Nonetheless, there are some advantages to this technique: 
It's easy to understand, easy to verify, and naturally supports
recursion and reentrancy.  It supports any number of parameters (unlike
registers) and is easily expanded.

5)  Pointers to parameter blocks.  This is similar to passing stuff in
the code stream except you pass an explicit pointer rather than using
the return address as the pointer.  Since you're passing a pointer, the
parameter block can be in RAM so this doesn't have the self-modifying
code problem.  This technique is really good if you can anticipate most
of the values you're going to pass to each call.  It works really well
if you pass the same set of parameters to various routines or to various
instances (calls) of the same routine.