Strings in BASIC

bbc micro/electron/atom/risc os coding queries and routines
Post Reply
Materion
Posts: 4
Joined: Sat Oct 17, 2020 3:00 am
Contact:

Strings in BASIC

Post by Materion » Sat Oct 17, 2020 10:11 pm

Hello,

Is space for strings allocated depending on how long string is ? Is there a way to tell BASIC that strinig A$ can be only 5 character long so it allocates memory only for this length?

Thanks in advance for replies ! ;)

User avatar
lurkio
Posts: 2925
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Strings in BASIC

Post by lurkio » Sat Oct 17, 2020 11:00 pm

From the BASIC ROM User Guide:
Mark Plumbley wrote:If the string is empty, no space needs to be allocated for it at all. If the string is a ‘small’ string (less than 8 characters), just the correct number of bytes is allocated on the HEAP for it. If it is a ‘large’ string, an extra 8 bytes are reserved for it, to allow some room for expansion (if this would take the allocated space over 255 characters, 255 bytes are reserved).

Whenever a dynamic string exceeds the space which has been allocated, a new area is reserved for it on the HEAP (using the same rules as above). The ‘gap’ left in the HEAP where the string used to be cannot be recovered (BBC BASIC has no ‘garbage collector’): so if memory is not to be wasted, it is usually a good idea to set strings, at the start of a program, to the largest size that they are likely to become.

The amount of memory wasted in this manner is not usually a great deal, but certain operations tend to use quite a lot (for example, a loop which adds one character on the end of a string each time round). In BASIC2 this has been improved by checking to see if the string is on top of the HEAP: if it is, it can be extended without having to throw away the old area.
viewtopic.php?f=42&t=13861#p182281

:idea:

User avatar
flaxcottage
Posts: 4256
Joined: Thu Dec 13, 2012 8:46 pm
Location: Derbyshire
Contact:

Re: Strings in BASIC

Post by flaxcottage » Sun Oct 18, 2020 10:01 am

Because of the above post, when using strings whose length is dynamic, I use the following code example;

A$=STRING$(32," "):A$=""

when declaring the string. In this case A$ has 32 bytes reserved for its length and then is set to null ready for use. A$ can now have any contents up to the maximum length of 32 without creating a new copy of itself on the heap once the length increases.
- John

Image

User avatar
Lardo Boffin
Posts: 2173
Joined: Thu Aug 06, 2015 7:47 am
Contact:

Re: Strings in BASIC

Post by Lardo Boffin » Sun Oct 18, 2020 10:12 am

I always try to minimise use of strings as much as possible and reuse where possible, setting the size (as per Flaxcottage’s post) to the largest possible usage.

In my adventure frame work (written in BASIC, link in signature and viewtopic.php?f=65&t=19303#p268318) I only use a couple of strings in total for inputting text, parsing it and displaying messages.
Adventure Language on GitHub
Atom, issue 5
Elk
A number of econetted (is that a word?) Beebs
BBC Master, Datacentre + HDD, pi co-proc, econet, NULA

User avatar
BigEd
Posts: 3450
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Strings in BASIC

Post by BigEd » Sun Oct 18, 2020 12:18 pm

flaxcottage wrote:
Sun Oct 18, 2020 10:01 am
Because of the above post, when using strings whose length is dynamic, I use the following code example;

A$=STRING$(32," "):A$=""

when declaring the string. In this case A$ has 32 bytes reserved for its length and then is set to null ready for use. A$ can now have any contents up to the maximum length of 32 without creating a new copy of itself on the heap once the length increases.
Not 32+8 bytes? I'm not sure how to check, but if the summary is right,
A$=STRING$(24," "):A$=""
would reserve 32 bytes. This seems to be so, according to Ruston's Compendium:
https://archive.org/details/BBCMicroCom ... 7/mode/1up
https://archive.org/details/BBCMicroCom ... 1/mode/1up

User avatar
flaxcottage
Posts: 4256
Joined: Thu Dec 13, 2012 8:46 pm
Location: Derbyshire
Contact:

Re: Strings in BASIC

Post by flaxcottage » Sun Oct 18, 2020 1:50 pm

I'm happy to stand corrected on that. The principle still holds though.
- John

Image

User avatar
BigEd
Posts: 3450
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Strings in BASIC

Post by BigEd » Sun Oct 18, 2020 1:50 pm

Yes, it's a good plan!

User avatar
BeebMaster
Posts: 3628
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Strings in BASIC

Post by BeebMaster » Sun Oct 18, 2020 2:52 pm

I get 58 bytes:
capture385.png
Partly this is due to reserving space for the two extra variables, then a byte each for them, but still seems a long way from 32 or 40.
Image

User avatar
BeebMaster
Posts: 3628
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Strings in BASIC

Post by BeebMaster » Sun Oct 18, 2020 2:57 pm

It seems 40 is the right answer for a 32-byte string.

DIM reserves 8 bytes for the floating point variable just created, and then the number of bytes requested (0 still reserves 1):
capture386.png
So 58-9-9 = 40
Image

User avatar
BeebMaster
Posts: 3628
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Strings in BASIC

Post by BeebMaster » Sun Oct 18, 2020 3:18 pm

I'm even more confused now:
capture389.png
capture390.png
This appears to show that there are 3 bytes for the floating point variable A and its DIM, with the first of those bytes containing the byte we poked into it, then 6 bytes apparently indicating the start of a string, then 32 bytes of the string data, then 16 more bytes of something or other before we get to the byte we poked into the floating point variable B.

Where are the variable names?
Image

User avatar
lurkio
Posts: 2925
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Strings in BASIC

Post by lurkio » Sun Oct 18, 2020 3:28 pm

BeebMaster wrote:
Sun Oct 18, 2020 3:18 pm
Where are the variable names?
A hint:

Screenshot 2020-10-18 at 15.26.56.png
Screenshot 2020-10-18 at 15.27.11.png

:idea:

User avatar
BeebMaster
Posts: 3628
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Strings in BASIC

Post by BeebMaster » Sun Oct 18, 2020 3:36 pm

Yes, it's because I was only using one-character variable names, and as BASIC maintains a separate list of pointers to each possible starting character's variables, the first character of the variable isn't stored in user RAM.
Image

User avatar
lurkio
Posts: 2925
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Strings in BASIC

Post by lurkio » Sun Oct 18, 2020 3:43 pm

BeebMaster wrote:
Sun Oct 18, 2020 3:36 pm
Yes, it's because I was only using one-character variable names, and as BASIC maintains a separate list of pointers to each possible starting character's variables, the first character of the variable isn't stored in user RAM.
Yes, this is explained well on page 49 of Plumbley's BASIC ROM User Guide (linked in my first reply to OP, above).

:idea:

User avatar
jgharston
Posts: 4121
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Strings in BASIC

Post by jgharston » Sun Oct 18, 2020 4:36 pm

DIM reserves space up to the final entry indicated, so DIM var 0 creates 1 entry, entry zero up to entry zero, not zero entries. You need DIM var -1 to get zero entries.
To avoid creating a variable in the heap and taking space from the heap, use a resident integer variable, eg DIM A% -1
So:
CLEAR:DIM A% -1:A$=STRING$(32,"*"):DIM B% -1:PRINT B%-A%

gives 48. 32+8 bytes reserved for A$, 8 bytes for the variable infomation block and the string information block:
variable info block:
xx+0/1 link to next variable
xx+2 '$' variable name
xx+3 &00 end of variable name
string info block:
xx+4/5 address of string storage
xx+6 size of string storage
xx+7 size of string

Different BBC BASICs use slightly differing string allocation methods, see link and link.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.32
(C) Copyright J.G.Harston 1989,2005-2020
>_

Post Reply

Return to “programming”