Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!ogicse!ucsd!ucrmath!feller!rhyde
From: rhyde@feller.ucr.edu (randy hyde)
Newsgroups: comp.sys.apple2
Subject: Re: ML subroutines (passing parameters in ML)
Message-ID: <13977@ucrmath.ucr.edu>
Date: 27 Apr 91 00:32:24 GMT
References: 112122@tut.cis.ohio-state.edu> <13954@ucrmath.ucr.edu> <52084@apple.Apple.COM>
Sender: news@ucrmath.ucr.edu
Reply-To: rhyde@feller.ucr.edu (randy hyde)
Lines: 31

Concerning that extra cycle on non-page align dp...

No offense Andy, but if I wanted to write in C, I'd write in C.
A one cycle penalty on a three cycle instruction is 25%.  You should see
how hard compilers work to get a 25% performance improvement.  If
everyone passed all their parameters on the stack and moved DP around as
you suggest to get local variables, they may as well be writing in C; 
well, perhaps not on the 65816, but if you're going to limit yourself to
writing code like the C or Pascal compilers do, there is very little
benefit to using assembly.  You certainly won't get the 5-10x
performance boosts I've been talking about.

Everyone has been jumping on me about telling people not to use the
stack as a parameter passing mechanism.  I did no such thing!  I simply
said it's bulkier and slower than passing in registers, in DP, etc... 
It IS!  I guess people have gotten so used to toolbox calls that they've
forgotten other ways to pass parameters!  If you can, passing your
parameters in A, X, and Y is always more convienient (and faster!) than
on the stack.  If you organize your program properly, using the
variables in dp is better.  If you must use a stack architecture, why
not set up two stacks?  Use the hardware stack for return addresses,
saving registers, etc., and set up a second stack (using DP as the
stack pointer) in another area of memory.  This is much easier than
messing with the stack itself (although you don't get the benefit of PH?
to set up parms).  A forth system on the GS used this scheme.

Ultimately, *your* choice of parameter passing mechanism depends on the
application at hand.  The stack is the appropriate vehicle for many
procedures and functions.  However, it's not a good idea to use the
stack as default without thinking the problem through first.  There may
be a better way.