tim@nijinsky.ipac.caltech.edu (Tim Conrow) (06/09/91)
Hi all, I apologize if this has been hashed over on the net already. Could someone please briefly describe what happens when the hp48 edits a large object, particularly wrt how much room is needed? I only have the standard user manuals, so a reference to one of the other manuals or books won't help. This request is prompted by the following: I have a 2442 byte program object. With >9k available in the calc I got an "insufficient memory" message upon hitting ENTER after editing the program (I only made a 1 character change). I was surprised by this. I tried turning off the last stack, last cmd and last arg memories and got the same result. I also tried recalling the object to the stack, purging the variable, and then editing. Still no soap. What gives? (BTW, I have only 32k born with the calc. and the eqlib card.) -- Tim tim@ipac.caltech.edu
edp@jareth.enet.dec.com (Eric Postpischil (Always mount a scratch monkey.)) (06/10/91)
In article <1991Jun8.225931.16298@nntp-server.caltech.edu>, tim@nijinsky.ipac.caltech.edu (Tim Conrow) writes: > Could someone please briefly describe what happens when the hp48 >edits a large object, particularly wrt how much room is needed? > This request is prompted by the following: I have a 2442 byte program >object. With >9k available in the calc I got an "insufficient memory" >message upon hitting ENTER after editing the program (I only made a 1 >character change). Caveat: I have not looked at the code; the following is from my own knowledge of software engineering. Consider what happens when you edit a program. First, there is a copy of the program in memory. Then, the 48 must create an ASCII representation of the program -- taking all the internal codes and changing them into S I N for SIN, or whatever else is in your program. You say your program is 2442 bytes, but how many bytes does it take to represent it in ASCII? This could well be thousands of bytes larger than the program itself, using up most of the remaining 9 kilobytes. Then when you press ENTER, the 48 must parse the ASCII string while building a new program object -- with the ASCII string and the old object still in memory. Programs should not be so large. You should break it into subroutines, so that they can be edited (and designed and conceived of) as parts. If you can transfer the program to another computer, you can edit it there and send it back in parts. -- edp (Eric Postpischil) "Always mount a scratch monkey." edp@jareth.enet.dec.com
herman@corpane.uucp (Harry Herman) (06/11/91)
In <23317@shlump.lkg.dec.com> edp@jareth.enet.dec.com (Eric Postpischil (Always mount a scratch monkey.)) writes: >In article <1991Jun8.225931.16298@nntp-server.caltech.edu>, >tim@nijinsky.ipac.caltech.edu (Tim Conrow) writes: >> Could someone please briefly describe what happens when the hp48 >>edits a large object, particularly wrt how much room is needed? >> This request is prompted by the following: I have a 2442 byte program >>object. With >9k available in the calc I got an "insufficient memory" >>message upon hitting ENTER after editing the program (I only made a 1 >>character change). >Caveat: I have not looked at the code; the following is from my own >knowledge of software engineering. Consider what happens when you edit >a program. First, there is a copy of the program in memory. Then, the >48 must create an ASCII representation of the program -- taking all the >internal codes and changing them into S I N for SIN, or whatever else is >in your program. You say your program is 2442 bytes, but how many bytes >does it take to represent it in ASCII? This could well be thousands of >bytes larger than the program itself, using up most of the remaining 9 >kilobytes. Then when you press ENTER, the 48 must parse the ASCII >string while building a new program object -- with the ASCII string and >the old object still in memory. I always thought the ASCII of a program was larger than the internal format as well, but while I was answering the original poster's questions through MAIL, I tried an experiment: 'directory' RCL DUP BYTES DROP DROP ->STR BYTES DROP DROP and noticed that the size shown by BYTES for the string version was SMALLER than the internal format version. This particular directory contains mostly numeric data in real-number format arrays and I use STD mode for display purposes (therefore the ASCII representation does not have unused decimal places), so milage may vary. However, the point is that you: 1) Cannot assume that the ASCII representation is automatically larger than the original, and: 2) The the size difference may not be significantly larger or smaller. Sure suprised the heck out of me! >Programs should not be so large. You should break it into subroutines, >so that they can be edited (and designed and conceived of) as parts. If >you can transfer the program to another computer, you can edit it there >and send it back in parts. I agree. > -- edp (Eric Postpischil) > "Always mount a scratch monkey." > edp@jareth.enet.dec.com Harry Herman herman@corpane