Jason Gloudon wrote:
> 
> On Mon, Mar 03, 2003 at 01:07:36PM +0000, Piers Cawley wrote:
> 
> > > I think you're overlooking the "restoreall" done just before the
> > > jump-no-save-returnaddress operation...  I see two "saveall"s and
> > > two "restoreall"s.
> >
> > But with proper tail call optimization you'd only need *one*
> > saveall. That's why it's an optimization.
> 
> Tail call optimization is a space (stack size) optimization. The
> scheme definition only requires space efficiency. The time
> optimization is important but a secondary consideration for the
> functional language folks.

Here's an idea -- considering that the first op of every sub seems to be
a 'saveall' instruction, and in my suggested optomized tail call
example, the one op immediately prior to the 'jsnr _bar' op was a
'restoreall', then the end of _foo might possibly have been written as:


   .arg int x # push @_, x
   .arg int u # push @_, u
   .arg int q # push @_, q
   branch (_bar + 1) # goto *second* op of sub _bar.
 .end

That is, go to the op immediately after the 'saveall'.

Thus, one saveall is performed, and one restoreall is performed.

The possible problems with this that I forsee are:

   1/ If _bar expects some data to be passed in with registers, rather
than with the stack.
   2/ If _bar does not have 'saveall' as it's first op.

If _bar is a subroutine generated by the compiler, neither of these
would ever actually occur in practice.

Well, they *could* occur if _bar was written by hand, not compiler
generated.  Then for each of the problem cases mentioned above:
   1/ If _bar expects some data to be passed in with registers, then
there's no possible way that it could be called by a compiler-generated
function and have behavior that's guaranteed to be consistent -- nor
should we expect this, or worry about it.  (Or, we could mark _bar as
expecting to be passed data through registers, and *forbid* it from ever
being called by compiler-generated subroutines, and only allow hand
written subs to call it).
   2/ The compiler can easily examine the first op of _bar, and if it
isn't 'saveall', choose not to make the tail call optomization.

-- 
$;=qq qJ,krleahciPhueerarsintoitq;sub __{0 &&
my$__;s ee substr$;,$,&&++$__%$,--,1,qq;;;ee;
$__>2&&&__}$,=22+$;=~y yiy y;__ while$;;print

Reply via email to