HP Forum Archive 06

[ Return to Index | Top of Index ]

Question about RPL stack Message #1 Posted by Chris Randle (Lincoln, UK) on 16 Oct 2001, 5:09 p.m. I'm reading an article about the 28C by Bill Wilkes. In it he writes, "Thus, when an object on the stack is duplicated, only the pointer is duplicated." I would read this as meaning that you have two pointers (identical values) pointing to the _same_ object. Is this what really happens? This would mean, as I understand things, that each object would have to employ some form of reference counting so that, when dropped, it wouldn't really be released until all stack references to it had been dropped. Any knowledgable person know if this is true? Just curious (and impressed if true).

Re: Question about RPL stack Message #2 Posted by Vieira, Luiz C. (Brazil) on 16 Oct 2001, 6:24 p.m., in response to message #1 by Chris Randle (Lincoln, UK) Hello, Mr. Randle; I do not have so much knowledge, but there is a single experience you would probably like to perform. Be sure to disable all recovery features (UNDO, LASTARG, LASTCMD, LASTSTACK, all in the MODES menu, if I am not wrong). Then, type MEM [ENTER]. Write down this value. Type in OR recall to the stack a somewhat big object (a program, a list, an array). If you recall it, MEM will return previous value LESS 2.5 bytes: the amouth of memory occupied by the LEVEL 1 pointer. The object IS NOT COPIED TO THE STACK, only the pointer to LEVEL 1 is created and is now pointing to the already existing object. If you typed in something, MEM will give you a new value, less than previous one. Press [ENTER] a few times (4, 5, just a few). Type MEM again; 2.5 bytes for each copy , O.K.? Pointers for the levels the object is SUPPOSED to be copied in are just pointing to the same object. How to change this? Edit one of them,change something and save the new, changed copied. In the stack, of course. say, edit the LEVEL 1 copy, remove or add something and press [ENTER]. MEM gives a lower available amouth of memory, now. Why? The edited copy is not a copy, is a new object which is pointed only by the LEVEL 1 pointer. Remove it by dropping it. MEM will lead to previous value, restoring the amouth of memory occupied by the edited copy as free, again. One tricky thing: create a program with HALT as its first command; execute it ([EVAL]); when it is halted, purge it from memory; do you believe that trying to continue execution would crash? WRONG! A complete copy of the program is created and, even if removed, the copy itself resumes AND is then erased from memory, with an operation known as Garbage Collection. Try it and, if needed, let us know. Regards. Oh, yes; donīt forget to restore previous MODES settings for the recovery reatures after doing all of this!

Re: Question about RPL stack Message #3 Posted by Chris Randle (Lincoln, UK) on 17 Oct 2001, 8:42 a.m., in response to message #2 by Vieira, Luiz C. (Brazil) Dear Mr Vieira, What a handy source of knowledge you are! Your instructions were clever. I'm annoyed that I didn't think of it. The results were just as you predicted. One thing you didn't mention (obvious, I suppose) is that you have to DROP the MEM result from the stack each time or else it affects the results. 1) Put a list on stack (-50.5 bytes = 48 for list, 2.5 for ptr) 2) DUP 5 times (-12.5 bytes = 5 x 2.5 byte ptrs. No extra for objects created) 3) Edit Level 1 list (-48 bytes, new list object created) 4) Edit back to previous values (No change. Not that clever!) 5) DROP & DUP (+48 bytes. 2nd list garbage collected) BTW, I never reset the last, undo and command modes until it's too late ;-) Enhanced version of my question (never ends!): EITHER the real objects maintain a count of the number of pointers that point to them and are destroyed when that count reaches zero, OR the garbage collection runs down the stack noting which objects were not referenced and deleting them. Anybody know which? My money's on the former, that's how I'd do it. If so, there must be a reference count per object overhead. What is it, if there is a "limitless" stack? Presumably 2 bytes so that a maximum of 65,535 pointers could reference it, which would exceed the 32k RAM? Sorry for being such an anorak, but I'm sure at least one other person here must understand my NEED to know these things :-)

Re: Question about RPL stack Message #4 Posted by Cameron on 17 Oct 2001, 10:38 a.m., in response to message #3 by Chris Randle (Lincoln, UK) --8X----- Sorry for being such an anorak, but I'm sure at least one other person here must understand my NEED to know these things :-) --8X----- ROFL Aha! The great GC vs reference counting debate in another domain. I'm not familiar with the calculator you're discussing (yeah, I am a philistine) but Luiz's idea about using the memory reporting function and his description of what happens suggests that reference counting, rather than GC, is being used. Fact: memory shrinks by a pointer size each time object is referenced. Fact: memory is reclaimed by a pointer size when a reference to an object is deleted. Background: one of the arguments for GC is that the reaper only needs run when the processor is "idle" or when memory needs to be reclaimed in a hurry. This maximises the amount of processor that is available for calculation rather than expending some of it managing references. (There is a counter argument that draws on the predictability of the time consumed by reference counting). However: the processor effort involved in faking the reported available memory to accommodate as-yet-unreaped pointers may be greater than the reference counting overhead. If this is so, it would tend to negate the benefit of a GC mechanism. (It would also make the firmware more complex). Conclusion: reference counting is used and the memory status accurately reports the available memory. Idle, perhaps frivilous, speculation. Nevertheless, I'm enjoying the discussion. Cameron

Re: Question about RPL stack - GC? Message #5 Posted by Vieira, Luiz C. (Brazil) on 17 Oct 2001, 10:43 a.m., in response to message #4 by Cameron I'm not acquainted to the meaning of GC. PLease, what is the meaning?

It's techno-babble for "garbage collection" Message #6 Posted by Cameron on 17 Oct 2001, 6:58 p.m., in response to message #5 by Vieira, Luiz C. (Brazil) My apologies Luiz (and anyone else that was puzzled by the term). I don't usually stoop to techno-babble in public writing. Thanks for drawing it to my attention. :-) Cameron

Re: Question about RPL stack Message #7 Posted by Vieira, Luiz C. (Brazil) on 17 Oct 2001, 10:39 a.m., in response to message #3 by Chris Randle (Lincoln, UK) Hello; as I have mentioned, I do not know so much. Thanks anyway! In fact, the pointers are bonded to the names they belong to , not to the objects they are poiting to. If each stack level points to the same object, the object itself does not concern of it. If no pointer points to it, the object will be (garbage) collected. I cannot go deeper, cause I did not make the homework already (reading some GOOD material till the end). A better, understanding analisys on pointers is found in many articles from the Gurus overhere (Mr. Willian C. Wickes, among many, many others, is one of the topmost). They will sure come after me. Best regards and thanks again.

Re: Question about RPL stack - an add Message #8 Posted by Vieira, Luiz C. (Brazil) on 17 Oct 2001, 11:51 a.m., in response to message #7 by Vieira, Luiz C. (Brazil) One point we must consider is that I have basically focused over stack reffered objects, as Mr. Randle's first subject sugests. In my previous post, where written "bond to the names they belong to", I'd rather try "bond to the STACK LEVEL they belong to". When stored as variables, object's use of memory and pointer reference is a bit different.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall