Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!ceres.physics.uiowa.edu!iowasp.physics.uiowa.edu!maverick.ksu.ksu.edu!kuhub.cc.ukans.edu!caen!uakari.primate.wisc.edu!samsung!mips!apple!stadler
Newsgroups: comp.sys.apple2
Subject: Re: ML subroutines (passing parameters in ML)
Message-ID: <52084@apple.Apple.COM>
From: stadler@Apple.COM (Andy Stadler)
Date: 26 Apr 91 23:13:41 GMT
References: <112122@tut.cis.ohio-state.edu> <13954@ucrmath.ucr.edu>
Organization: Apple Computer Inc., Cupertino, CA
Lines: 49

In article <13954@ucrmath.ucr.edu> rhyde@dimaggio.ucr.edu (randy hyde) writes:
>>> Its quite simple (to access parameters on the stack) if you point the
>   direct page at the stack...
>
>True, it's easy, but you give up two important things about the direct page--
>the ability to use it as a set of 256 scratch pad registers, and furthermore,
>it's doubtful the dp would be page aligned costing you another cycle on each
>dp memory access.
>
>I've often wondered why compilers insist on using the dp as a frame pointer
>rather than fixing dp (or pseudo-fixing it) and using register allocation
>schemes like a RISC machine.  The resulting code would run quite a bit faster.

On this point I must respectfully disagree.  First, you -can- get "scratch"
registers.  In the world of high level languages they are called "local
variables."  Rare is the subroutine which actually uses 256 bytes of param-
eters- so you just subtract a bit from the stack on your procedure entry, and
use the direct page for parameters AND local variables.  Here's a picture:

	|-----------------|
	| function result |
	|-----------------|
	|      ...	  |
	|   parameters    |
	|      ...	  |
	|-----------------|
	|      RTL	  |
	|-----------------|
	|      PHD	  |
	|-----------------|
	|      ...	  |
	|   local vars	  |
	|      ...	  |
	|-----------------|
   DP ->|		  |<- SP

Even with 50 bytes of parameters you'd still have over 200 bytes of scratch
pad storage - and it's all useful as pointers because it's on the direct page.
And, because it's on the stack, it's automatically protected when you call 
other routines, and it's by definition recursive and reentrant.

On your second point, that it's inefficient because of the non-aligned DP, I
will grant you that this it true;  on the other hand, if you have a loop which
is so tight that the one cycle loss is too much, then you shouldn't be in high
level!  But let's be honest here!  How many loops in a large program actually
require that much tightness?  Very few!

Andy Stadler
Apple Computer, Inc.