home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.sys.tandy      Life is dandy cuz you're gettin a Tandy!      5,684 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 5,327 of 5,684   
   George Phillips to Charles Richmond   
   Re: TRS-80 Microsoft BASIC String Space    
   12 May 14 11:19:05   
   
   From: gp2k00@gmail.com   
      
   On Friday, May 9, 2014 12:56:33 PM UTC-7, Charles Richmond wrote:   
   > I am looking for some references online to a problem with compressing the    
   > string space in Microsoft BASIC on the TRS-80.  My recollection is that as    
   > string space becomes low, the compression algorithm fails and an "OUT OF    
   > STRING SPACE" error occurs when in reality there is enough string space    
   > left.   
      
   I've not heard of this, but I have looked at the string space packing and   
   string routines in the ROM.  The string packing algorithm doesn't look like it   
   will fail when string space is low.  String expression evaluation may take   
   more space than is    
   expected.  For instance, A$=CHR$(32)+CHR$(33) will use up 4 bytes of space as   
   each of the CHR$() values will need 1 byte and their concatenation another 2   
   bytes.  Then the assignment happens at which point there will only be two   
   bytes used with the other    
   two left as garbage to be collected later.   
      
   The original value of A$ itself will end up as garbage as well but won't be   
   available for re-use until after the assignment.  This can lead to situations   
   that might be regarded as an error.  Consider the following program:   
      
   10 CLEAR 50   
   20 A$=STRING$(47, "*")   
   30 A$=CHR$(1)+CHR$(2)   
      
   This will result in "?OS Error in 40" because by line 30 there are only 3 free   
   bytes of string space and 4 are needed to evaluate the expression though we   
   might think that only 2 free bytes are necessary.  In fact, we might even   
   assert that no free bytes    
   are needed because the first step should be to throw away A$.   
      
   In either case, I think that's too much to expect of the BASIC interpreter.    
   It can't always decided to kill the left hand side of an assignment because   
   the right-hand side may depend on the value (e.g., A$=LEFT$(A$,1)).  Nor can   
   we reasonably expect it    
   to have additional code to optimize special cases.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca