Notes on the Use of BASCOM #1

			STRING SEGMENTING

		(C) Copyright 1985 Merlin R. Null
			 (818) 762-1429

BASCOM  does optimization  of  string  storage  in  the  compiled
program by matching strings of more  than  four  bytes.   Only  a
single copy of the matched  string  is  stored  in  the  compiled 
program  (unless the /S switch is used with the  compiler).   You
can cause this feature of the compiler to shorten your program by
deliberately breaking strings into matching segments.

For example:

100 PRINT"File not found - please try again"
.
.
200 PRINT"Bad file name - please try again"

Both of these strings would be stored in  full  in  the  compiled
program, even though parts of them match.  To allow BASCOM to see
the match and shorten up the string space, change them to:

100 PRINT"File not found";" - please try again"
.
.
200 PRINT"Bad file name";" - please try again"

The break in the string with  ";"  allows BASCOM to treat them as
two distinct strings.   To verify that you did it correctly, dump
the COM file in PATCH, EDFILE or DDT and look at the string space
in the ASCII portion of the dump.   You  should see only one copy
of  " - please try again"  or whatever the strings were you tried
to match.   The strings must be absolutely identical, down to the
last space, to be matched.   In the above example,  4 bytes would
be saved in the compiled program.   If  there  were  3  of  these
strings to be matched, the savings would be 17 bytes.  4 strings,
would save 30 bytes.

The main drawback to this is that it will  be  more  difficult  to
read and patch  the  compiled  program  directly.   In  the  above
example, if you were to patch the string  " - please try again" to
" - arrgh, forget it",   all  places  in  the  program  that  used
" - please try again" would change.   This  might be exactly  what
you want, if you are not releasing the source to your program  and
want to make it more difficult to modify.

The minimum string length which will result in saving bytes in the
compiled program depends on the number  of strings  matched.   The
following chart gives the number of bytes saved for various string
lengths and number of matching strings:


	      BYTES SAVED WHEN STRINGS ARE MATCHED

Number of |	    Number of bytes in a single string
Identical |
Strings   | 7   8   9  10  11  12  13  14  15  16  17  18  19  20
=================================================================
    2     | -   -   -   -   -   -   -   -   0   1   2   3   4   5
    3     | -   -   -   -   1   3   5   7   9  11  13  15  17  19
    4     | -   -   0   3   6   9  12  15  18  21  24  27  30  33
    5     | -   -   3   7  11  15  19  23  27  31  35  39  43  47
    6     | -   1   6  11  16  21  26  31  36  41  46  51  56  61
    7     | -   3   9  15  21  27  33  39  45  51  57  63  69  75
    8     | -   5  12  19  26  33  40  47  54  61  68  75  82  89
    9     | -   7  15  23  31  39  47  55  63  71  79  87  95 103
   10     | 0   9  18  27  36  45  54  63  72  81  90  99 108 117


Points on the chart marked  "-"  indicate  an increase in program
size.   This  chart  was  prepared  by  compiling  short programs
containing only strings to print to the screen.   For the  actual
saving in bytes, compare the bytes used or bytes free reported by
L80 at the end of linking.  The number of bytes free  reported by
BASCOM does not show the savings.   BASCOM  will  report the file
with the divided strings as longer.  The source file IS longer.

The number of bytes saved is not hugh,  but it might be just what
is need to shrink a program down to the next lower block size.

Of course,  an even easier way to shrink a program is to edit the
strings.   Does  your  program  have  a  paragraph  or  a page of
explanation where a line  or  two  might  do  the  job?   Useless
verbiage on a screen can lead to it not being  read  at  all.   A
help file might have a lot of text, but the main program  prompts
should be short and to the point.

						6-24-85