Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpfcso!hpfinote!rrd
From: rrd@hpfinote.HP.COM (Ray Depew x2419)
Newsgroups: comp.sys.handhelds
Subject: Re: HP 48 revisions
Message-ID: <19080010@hpfinote.HP.COM>
Date: 19 Sep 90 04:42:43 GMT
References: <25590057@hpcvra.CV.HP.COM>
Organization: Hewlett Packard CICD
Lines: 60


>	An unfriendly behavior of the 48 which I have run afoul of several
>times, but have never seen listed as a bug, involves INPUT (by the by, I
>have a Revision D ROM). Try the following:

>    \<< "" "" INPUT
>        DO
>        UNTIL 0
>        END
>    \>>

>INPUT puts the 48 into Program Entry Mode, but PROGRAM ENTRY MODE IS NOT
>EXITED once INPUT has done its job! The command line, with an ugly frozen
>cursor, is still displayed while the DO loop runs. Dr. Wickes, is this a
>bug? It seems to me that INPUT should leave the machine in the same state
>it found it in -- i.e., Program Entry Mode should be cleared.


Don't worry; your SYSEVALS had nothing to do with it.  It's not a bug,
either.  The computer -- oops, sorry, the machine -- is doing just what
you told it to do.

Your   << ... "" "" INPUT ... >> line obviously prompted for a command-line
input, which of course you keyed in and then pressed [ENTER].  Then
you entered an endless loop:  << ... DO UNTIL 0 END ... >>  which the 48
obediently executed.  It ran through the loop, checking every time to see
if the zero had become a one yet.

Now, the problem is that you *expected* the 48 to update the display
immediately after executing the INPUT and before executing the DO-UNTIL.
It doesn't.  I don't know why; I haven't figured that part out yet.  However,
I think that to enhance computation speed, the 48's designers choose to 
"freeze" the display during program execution, except for commands which
obviously affect the display (e.g. PVIEW or DISP).

You can see this if you run a l-o-n-g program which modifies the stack 
at the beginning.  For example, try the program

     << SWAP 1 1000 FOR j 1 STEP >>

You would *expect* to see the Level 1 & 2 arguments swapped immediately,
but they don't*appear* to be swapped until the program ends.  (You can 
change the number 1000 to anything else, to enhance the effect.  1E99
is too big, though.  :-)  And yet, you and I KNOW that the swap occurred
at the start of the program.

This is not, repeat NOT, a bug.  It belongs there.  It makes for some 
remarkably professional-looking, seamless routines.  Consider it a 
descendant of the programmable VIEW command of HP-41 days (ah, the 
wonders of yesteryear!).

And remember Funky Winkerbean's Third Axiom of Computer Programming:
A computer doesn't do what you WANT it to do, only what you TELL it to do.

----------
Regards
Ray Depew
HP Colorado IC Division 
rrd@hpfitst1.hp.com
just another satisfied etc.