From: pshuprs@prism.gatech.EDU (Howlin' Bob)
Newsgroups: comp.sys.hp48
Subject: machine language tip
Date: 5 Oct 92 19:09:52 GMT
Organization: Georgia Institute of Technology

Just a tip for those of you learning machine language on the HP48 who
are JUST smart enough to shoot yourself in the foot...
 
Be careful when working with objects on the stack and calling ROM
subroutines that may call GARBAGECOL (either directly or indirectly)
at #613E.  Most of these routines will involve some sort of memory
allocation, such as the string allocation commands MAKE$N and MAKE$,
any routine that pushes something onto the stack, etc.
 
Let me tell you my story first...Using my first real ML program,
a string reverser, I noticed an odd bug.  Strings close to the size
of free mem would reverse once fine, but would be corrupted on the
second reverse.  This problem has appeared intermittently over the past
month or so, and only this week has the answer finally hit me...
 
You see, I did something like this:
   a=dat1	a	* get the address of the level1 string
   d1=a		a
   d1=d1+5	a	* point to size field
   c=dat1	a	* c=size of string
   d1=d1+5	a	* point to string body
   ad1ex	a
   r2=a		a	* save ptr to string body
   gosbvl	=MAKE$N	* allocate string of C.A nibbles, str ptr returned
			* in R0, D0=R0+0xA  ( ptr to string body )
 
   ...then I did some copy stuff here, from the old string pointed to in
      R2.A to the new string pointed to in R0.A
 
except that, if MAKE$N found that I didn't have C.A (give or take about 21)
nibbles free, it called GARBAGECOL.  And, most likely, my string at
stack level 1 got moved during GC.  Meanwhile, my program ran happily along
with an incorrect address, reversing "random" trash into my new string.
 
To avoid this, ALWAYS re-read your addresses off the stack after you call such
a function.  If you're using a temporarily allocated object as a data
space, push it onto the stack if you think you might call a GARBAGECOL-
calling function.  This lets the GC system know that it's still a relevant
object.  I'm not sure where else it checks for references, but it might be
possible to shove your pointer into the LASTSTACK system-var, too.
Anyway, when you're done, pop your address off the stack or remove it
from whatever nook or cranny you've found to work, so that your program
doesn't leave its temporary gibberish laying around.
 
Anyway, those of us used to UNIX or PCs, or AMIGAsm or whatever, memory 
allocation on the HP48 doesn't work like malloc()!  It works more like
allocation on the MAC, except you don't get the neat handle interface.

For example, There is NO DE-ALLOCATION!  DeALLOCATION consists of de-
referencing (not in the sense of dereferencing a pointer...oh, dear,
I'm being vague...I mean "remove all the references to") your block of
mem. 

Anyway, I've rambled enough.  Those of you who know this, remember your
problems learning/discovering it (of course, it's all very clear in
hindsight for me.  Garbage collection just wasn't as real to me then
as it is now).  Those of you who don't, I hope you are ambitious enough
to need it.
 

-- 
Robert Sanders 
Georgia Institute of Technology
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!pshuprs
Internet: pshuprs@prism.gatech.edu     OR  gt8134b@prism.gatech.edu
From: akcs.joehorn@hpcvbbs.cv.hp.com (Joseph K. Horn)
Date: Tue, 6 Oct 1992 08:40:05 GMT
Subject: Re: Regressions
Message-ID: <2ad14470.1852.1comp.sys.hp48.1@hpcvbbs.cv.hp.com>