Extraordinary String Animals: Difference between revisions

From Bitchin100 DocGarden
Jump to navigationJump to search
m (Spelling and grammer corrections only.)
m (Reverted edits by Shaina (Talk); changed back to last version by Ronw)
 
(One intermediate revision by the same user not shown)
(No difference)

Latest revision as of 16:50, 5 June 2010

Ron Wiesen, in response to a question from Wilson Van Alst:

To your first question: the situation of $trings (i.e., where they sit) in the $tring-space can set the stage for a compelled 'garbage collection' that takes place, as a neccessary prelude, to a subsequent $tring operation. In other words, the $tring-space holds existing $trings which are not adjoined (unused gaps of space are between $trings) and then the BASIC interpreter encounters some $tring operation. The total volume of unused $tring-space is sufficient to support the $tring operation. But that total is fragmented due to the way existing $trings are situated in the $tring-space. This compels the BASIC interpreter to suspend interpretation, conduct 'garbage collection' in order to consolidate the unused volume into one contiguous span, and then continue with interpretation -- performing the $tring operation.

To your second question: you've overlooked the "extraordinary" $tring animals. These creatures begin their life born as ordinary $tring animals (typically 0-length nuls). They then mutate into "extraordinary" $tring animals of some finite (often substantial) length. What makes these creatures "extraordinary" $tring animals is that their related $tring content is ROM-based (not RAM-based in the the $tring-space). Below is an example of how an "extraordinary" $tring animal is brought into existance.

E%=32676:E$="":
POKE0+VARPTR(E$),25:POKE1+VARPTR(E$),E%MOD256:POKE2+VARPTR(E$),E%\256

E$ was born as an ordinary $tring animal with a LENgth of 0 (nul). In the ROM-space, address 32676 is the locale of a 25-cell that holds a bunch of values that are ASCII character codes.

Note that the $tring variable called E$, like any other type of variable, lives in the variable-space within RAM. In the case of a $tring variable, the variable-space holds two attributes: LENgth, and Address_of_content. The function VARPTR, as applied to a $tring variable, returns the locale of the LENght attribute. So 0+VARPTR(E$) is the locale for LENgth of the $tring variable called E$. In the variable-space for a $tring variable, the LENgth attribute is immediately followed by the Address_of_content attribute. So 1+VARPTR(E$) and 2+VARPTR(E$), respectively, are the Least significant and the Most significant halves of the locale for Address_of_content of the $tring variable called E$. Via three POKEs, the creature called E$ mutates into an "extraordinary" $tring animal.

Sure, go ahead. Do a PRINT E$ statement in order to discover what the ROM-based content looks like (you can't resist the temptation).

What makes the "extraordinary" $tring animals so extraordinary in contrast to ordinary $tring animals? Although both of these creatures live in the variable-space, as do creatures of all variable types, they obtain their runs of character codes from radically different media. The ordinary $tring animal "feeds" from RAM media: within a BASIC statement in the case of "literal" food, or within the $tring-space in the case of changeable food. The "extraordinary" $tring animal "feeds" from ROM media where all food is "literal" in the sense that it's cast in stone (i.e., silicon).

To your third question: you've overlooked whether or not the BASIC interpreter recognizes the difference between an ordinary $tring animal and an "extraordinary" $tring animal. Offhand, I don't have a concrete answer. Whenever I have occasion to create "extraordinary" $tring animals, most of the time they are of very substantial LENgth yet there is no operational program activity that would amount to exposure to "garbage collection" events. However, I dimly recall investigating the question a long time ago. As I recall, I was delighted and surprised to discover that the BASIC interpreter does recognize the difference between ordinary $tring animals and "extraordinary" $tring animals such that the potential for, and management of, "garbage collection" events is not impacted by the existence of "extraordinary" $tring animals. At least that's what I recall. My recollection likely is accurate given how the BASIC interpreter already recognizes those ordinary $tring animals that have "literal" food in a BASIC statement -- to the BASIC interpreter, those creatures perhaps "look the same as" any existing "extraordinary" $tring animals with respect to "garbage collection" considerations.