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
String garbage collection
Re: String garbage collection
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
just for fun, I'll try creating a few thousand random length strings and see how the GC reacts.
Re: String garbage collection
So yeah, you can really bring the machine to a crawl with garbage collection.
Consider this:
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-T1The 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
"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.
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
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
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
-
- Posts: 140
- Joined: Tue Jul 21, 2020 10:08 pm
Re: String garbage collection
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
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
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.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
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.
-
- Posts: 140
- Joined: Tue Jul 21, 2020 10:08 pm
Re: String garbage collection
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.TomXP411 wrote: ↑Fri Jun 23, 2023 3:28 amFYI, 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.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
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.
I'm having problems getting the r43 emulator to work with local storage operating system - I can't save or load anything right now