Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!jarthur!sburke
From: sburke@jarthur.Claremont.EDU (Scott Burke)
Newsgroups: comp.sys.handhelds
Subject: Re: CLEARing stack
Keywords: CLEAR
Message-ID: <10550@jarthur.Claremont.EDU>
Date: 29 Jan 91 21:43:09 GMT
References: <10535@jarthur.Claremont.EDU> <19558@shlump.nac.dec.com>
Organization: Harvey Mudd College, Claremont, CA 91711
Lines: 60

In article <19558@shlump.nac.dec.com> edp@jareth.enet.dec.com (Eric Postpischil (Always mount a scratch monkey.)) writes:
>In article <10535@jarthur.Claremont.EDU>, sburke@jarthur.Claremont.EDU (Scott
>Burke) writes:
>
>>  1. There may be a large object on the stack, and if you want your code to
>>     run in low memory conditions, it is a _really_ bad idea to stick those
>>     1K GROBs (to pick an example) in a list and try to store it.
>
>Why is that?  Supposing that you disable argument/stack saving temporarily and
>convert the stack to a list to be stored in a variable, are extra copies of the
>items on the stack created during this?  Or does the 48 just move them around?
>
>
>				-- edp (Eric Postpischil)
>				"Always mount a scratch monkey."
>				edp@jareth.enet.dec.com

You've got a correct point here, sort of...  ;-)  It _is_ possible to disable
Last Arguments from a program by setting flag -55.  However, it is _not_
possible to disable Last Stack (i.e., flush the Last Stack buffer).  Last
Stack most likely uses an approach like storing the previous stack in a list
somewhere, and then restoring that list when Last Stack is pressed.  However,
to clear the Last Stack buffer requires either an ON-C (not terribly feasible
from within a program) or a 0 DROP (to place a 0 in the buffer) _from the
keyboard_!  If the program does a 0 DROP it won't affect the user stack.
Therefore, whatever is in Last Stack is not changeable by a program without
a HALT statement.

You are correct (I've been doing some fiddling in lo-mem situations) when
you say that the 48 just moves things around, _except_ for this case:  If
the user has merely recalled a GROB (to pick an example) to the stack, then
all that is on the stack is a pointer to the stored GROB.  If your program
proceeds to create a list of the stack, it is forced to do a NEWOB to make
a copy of that GROB to go into the list, thereby eating memory.  On the other
hand, if the GROB really is a new item on the stack to begin with, you don't
lose anything by hiding it away in a list, because the GROB was already 
occuping space in Temporary Object Memory.  But you just don't know if the
stack is pointers or real objects, so it can't hurt to leave it alone.

I agree that for speed and space, CLEAR is nice.  Although you still have to
error trap (to have a chance to CLEAR after an ATTN press), you don't have to
write the code to muck with the stack depth counter.  And if your code does
not have to access the stack (or provide Interactive access to it), binding
it in a list may not be a terrible solution, and will let you use CLEAR.

Let me throw out another idea for discussion:  How many ATTN presses should a
commercial piece of software trap?  Impatient (or ignorant) users may be 
inclined to press that dumb key a whole bunch if they don't perceive that 
anything is happening (or if they don't know about the Hourglass symbol).
For example, Donnelly's QSORT ignores ATTN presses and goes right on ahead
to finish the sort.  This means that a user sorting a lot of data may very
well push ATTN four or five times and then give up and wait.  As soon as the
QSORT call is completed, WHAMMO your code crashes because you didn't trap 
enough ATTN presses, and you leave 85 data items and a bunch of garbage on
the stack!  At what point should you throw up your hands and say, "I can't 
use internal code, so I'm doomed!"?

Scott.

sburke@jarthur.claremont.edu