Page 1 of 1
String garbage collection
Posted: Sat Jun 10, 2023 3:03 am
by Martin Schmalenbach
Apologies if this has been covered elsewhere- I searched and couldn’t find anything specific on it…
Does the string garbage collection still get triggered by the FRE() function as well as automatically?
And does the CX16’s version of BASIC suffer the same garbage collection flaws of BASIC 2, namely that it can take hours to garbage collect if there are a great many strings…?
Thanks in advance.
Cheers
Harry
Re: String garbage collection
Posted: Sat Jun 10, 2023 3:52 pm
by BruceRMcF
I don't know if there has been any fix to it in the past few years, but previously it was the C64 garbage collector. If it still is, then someone who knows the innards of the C128 were to borrow from the C128 Basic code, that was at the original github site, that would be a substantial improvement, since the C128 had a better garbage collector.
Re: String garbage collection
Posted: Sun Jun 11, 2023 3:57 am
by TomXP411
just for fun, I'll try creating a few thousand random length strings and see how the GC reacts.
Re: String garbage collection
Posted: Sun Jun 11, 2023 4:14 am
by TomXP411
So yeah, you can really bring the machine to a crawl with garbage collection.
Consider this:
10 CLS
20 N=1000
30 T1=TI
40 M1=0:M1=FRE(0)
50 LOCATE 2,1:PRINT M1
60 DIM A$(N)
70 FOR I=1 TO N
80 A$(I)=STR$(I)
90 PRINT "\X13";I
100 NEXT
110 M2=M1-FRE(0)
120 LOCATE 3,1:PRINT M2;M2/N
130 T2=TI-T1
The counter gets to 1000 pretty quickly, then stops for several seconds. Finally, it displays the memory count. I put that down to GC taking time to do its thing.
Re: String garbage collection
Posted: Sun Jun 11, 2023 6:38 pm
by mobluse
"I found this bug in all versions of Commodore BASIC, that I investigated, VIC-20, C64, C128, C65, MEGA65."
https://c65gs.blogspot.com/2021/03/gues ... ixing.html
But I guess that the bug is now fixed in MEGA65. I don't know if it was fixed in Commander X16.
Re: String garbage collection
Posted: Sat Jun 17, 2023 4:19 am
by Xark
Hello,
This bug did appear to be present in X16 BASIC, so I made a one-line PR and MooingLemur has merged it, so X16 should not hit this bug now.
https://github.com/X16Community/x16-rom ... e80192ed7e
Thanks for mentioning this!
-Xark
Re: String garbage collection
Posted: Fri Jun 23, 2023 12:43 am
by Martin Schmalenbach
Thanks to all for the discussion, including about the weird bug.
It looks I will still need to make use of various 'cheats' in handling temporary string storage - not temporary at the BASIC ROM level, but temporary at the level of my own application, a compiler. Not a problem!
Cheers
Martin
Re: String garbage collection
Posted: Fri Jun 23, 2023 3:28 am
by TomXP411
Martin Schmalenbach wrote: ↑Fri Jun 23, 2023 12:43 am
Thanks to all for the discussion, including about the weird bug.
It looks I will still need to make use of various 'cheats' in handling temporary string storage - not temporary at the BASIC ROM level, but temporary at the level of my own application, a compiler. Not a problem!
Cheers
Martin
FYI, a set of variable pointer functions have recently been added, which you can take advantage of for string storage. with POINTER and STRPTR, you can manipulate strings directly in memory.
For example:
10 A$=RPT$(32,80)
20 AP=STRPTR(A$)
30 POKE AP+1,64
This allocates an 80 byte string, then changes the first byte to an @ symbol.
There's a lot you can do once you have access to the variable table (with POINTER) and the string data, such as move a string to a different location in memory, or set up an array so that it reads a series of strings in high RAM.
Re: String garbage collection
Posted: Fri Jun 23, 2023 6:34 am
by Martin Schmalenbach
TomXP411 wrote: ↑Fri Jun 23, 2023 3:28 am
Martin Schmalenbach wrote: ↑Fri Jun 23, 2023 12:43 am
Thanks to all for the discussion, including about the weird bug.
It looks I will still need to make use of various 'cheats' in handling temporary string storage - not temporary at the BASIC ROM level, but temporary at the level of my own application, a compiler. Not a problem!
Cheers
Martin
FYI, a set of variable pointer functions have recently been added, which you can take advantage of for string storage. with POINTER and STRPTR, you can manipulate strings directly in memory.
For example:
10 A$=RPT$(32,80)
20 AP=STRPTR(A$)
30 POKE AP,64
This allocates an 80 byte string, then changes the first byte to an @ symbol.
There's a lot you can do once you have access to the variable table (with POINTER) and the string data, such as move a string to a different location in memory, or set up an array so that it reads a series of strings in high RAM.
How funny - while you were sharing this here on the forum I was in r43 playing with these very functions and looking at how they worked via the MONitor. Sweet! And thanks for the example - most helpful.
I'm having problems getting the r43 emulator to work with local storage operating system - I can't save or load anything right now