S/SuperBASIC Arrays

Anything QL Software or Programming Related.
qbits
Trump Card
Posts: 171
Joined: Sun Dec 11, 2016 3:32 pm

S/SuperBASIC Arrays

Post by qbits »

Question:
S/SuperBASIC and the use of DIM and Array memory allocation, if DIM Grid(col,row) is used by a PROCedure and is repeated several times through the running of a Program with (col,row) numbers kept the same or possibly changed, how is memory effected is it reallocated each time or only if (col,row) are changed and is the old memory automatically released every time.

For example Array Size of col=80 row=40 (Integer x2 bytes ; Floating point x6 bytes).
What are likely to be the performance issues with large Arrays on say a BBQL assuming extended memory with TK2 or with QPC2 installed.

QBITS


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: S/SuperBASIC Arrays

Post by tofro »

  1. Arrays are always passed by reference. That is, even if you use an array as a function or procedure parameter, the function or procedure will always work on the original. Nothing is being copied back and forth between the caller and the callee.
  2. Re-DIMensioning an array clears it. Clear means "empties" it, the array elements will probably end up in a different place in memory - it's allocated completely new from scratch, even if the dimensions are the same as before. Caveat: Turbo does that a bit differently : If you re-dimension an array only in the last dimension, Turbo will not touch the existing contents - that's what they call "rubber arrays" . If you want to clear an array by re-DIMming it in Turbo, you must make sure you change not only the last dimension (you might therefore need to DIM twice).
  3. Whenever you DIM something that was there before, regardless of whether you change any of the dimensions or not, the whole thing will be allocated completely anew, and the old allocation thrown away. That makes sure everything is deleted as it should. That also means that, regardless whether you re-DIM an array in the main program or in some PROC or FUNC, you will always re-DIM the same thing (because it's passed by reference).
  4. The above means that there actually is only one instance of a specific array at any point in time in the program - With an exception when LOCal variables "hide" global ones. In case you have a global a$ and a local array of the same name, that local will "hide" the global for all PROCs and FUNCs called from there on. Otherwise, everything else stays as above. That also means that a re-DIM somewhere in the call chain will re-DIM the LOCal, not the global array.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: S/SuperBASIC Arrays

Post by pjw »

It shouldnt be hard to devise a small test rig to see whether such a method eats memory by fragmenting it. (Just note that SBASIC, SuperBASIC, and compilers may all behave differently.)

I did a lot of tests over questions like this back in the day. Although I cant now remember the exact results, I trust they have been incorporated into my coding habits..

That being the case, I doubt Id ever use DIM in procedures in the way I understand your description. There are many ways to minimise memory fragmentation when using arrays. Until someone writes the Definite Guide the safest bet is to experiment!


Per
dont be happy. worry
- ?
qbits
Trump Card
Posts: 171
Joined: Sun Dec 11, 2016 3:32 pm

Re: S/SuperBASIC Arrays

Post by qbits »

Thanks. Your comments confirmed more or less my own thoughts and recall on the subject, although an added Caveat: with what might happen with different compilers. I guess this a judgment call over memory usage. I could just DIM multiple arrays as memory is a lot less restricted than in the past. I could reset the Array with zero’s as part of the S/SuperBASIC Prog, this will have less impact on memory allocation and fragmentation of the Heap.. but is far slower than just re-DIMensioning the Array.

Thanks again for your comments
QBITS


stevepoole
Super Gold Card
Posts: 712
Joined: Mon Nov 24, 2014 2:03 pm

Re: S/SuperBASIC Arrays

Post by stevepoole »

Hi Qbits,

If you DIMension an array as, say, DIM T(1,2,3) in TURBO you need to clear it with DIM T(0) before redimensioning it...
Turbo calls this using RUBBER Arrays.

Steve.
_______________


Tinyfpga
Gold Card
Posts: 252
Joined: Thu Sep 27, 2018 1:59 am

Re: S/SuperBASIC Arrays

Post by Tinyfpga »

Whilst trying to understand how to use arrays in basic I quickly discovered that I could use variables as array indices.
Great, I thought, this would indicated that SBASIC arrays could be resized dynamically. Sadly this turned out not
to be the case when using Qliberator to compile my source code.

tofro's informative second paragraph makes it clear why this is the case.

Given that SMS is memory resident and has dynamically allocated RAM discs it seems odd that SBASIC arrays are
not dynamic. It seemed to me that dynamic arrays could be a very useful way of storing data so I tried to write an SBASIC
algorithm that would allow arrays to be resized dynamically.
The only way I could think of doing this was to save the data held in the array, resize it, load the data back into the array and then delete the saved information. This seems inefficient and wasteful (if saved to ram disk) but it works. I did not want to
use two arrays to do this task because it seemed an even worse method.

Has anyone created a dynamic array or knows of a better way (in BASIC) of making arrays resizeable without clearing the array.


User avatar
janbredenbeek
Super Gold Card
Posts: 629
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: S/SuperBASIC Arrays

Post by janbredenbeek »

Tinyfpga wrote:Whilst trying to understand how to use arrays in basic I quickly discovered that I could use variables as array indices.
Given that SMS is memory resident and has dynamically allocated RAM discs it seems odd that SBASIC arrays are
not dynamic. It seemed to me that dynamic arrays could be a very useful way of storing data so I tried to write an SBASIC
algorithm that would allow arrays to be resized dynamically.
The only way I could think of doing this was to save the data held in the array, resize it, load the data back into the array and then delete the saved information. This seems inefficient and wasteful (if saved to ram disk) but it works. I did not want to
use two arrays to do this task because it seemed an even worse method.

Has anyone created a dynamic array or knows of a better way (in BASIC) of making arrays resizeable without clearing the array.
The problem is that arrays need to be in contiguous memory. In QDOS, you cannot just extend a block of allocated memory without making a new allocation and moving the old data there. On the other hand, dynamically allocated RAM disks do not need a contiguous memory block because the files are allocated in blocks of 512 bytes, and a table keeps track of which blocks belong to which file. It's a sort of linked list - you allocate one block, and if you need more memory you just allocate another block with a pointer in the first block pointing to it. So when looking for a specific element you have to follow the links as you count, which will be quite slow (or you would need to build an array of pointers to the actual data, but then you'd run into the same problem - how many elements would you allocate, and what if the array needs to be extended). It's a pity that S*BASIC doesn't provide for pointers and linked lists as languages like Pascal or C do.

The original implementation of SuperBASIC is special in that it's data areas can expand and contract dynamically, unlike other jobs. However this doesn't provide for dynamic arrays. (I'd say that Sinclair BASICs have always been a bit more restrictive than others, in that strings in a string array don't have dynamic length - remember the Spectrum's 'procrustean lengthening'?). Also, the need for relative adressing with respect to a base register (A6) makes programming relatively complex and resulting code slower.

Minerva does provide for MultiBASICs, even with dynamic data areas, but AFAIK if a MB job other than 0 needs more memory it does so by allocating a larger area and moving the old data there. I believe SMSQ/E will do the same for all S*BASIC jobs. The drawback of this (and linked lists) is that heap memory will eventually become fragmented, although in present times with many megabytes of RAM this will be less of a problem than when you had only 128K to play with...


Tinyfpga
Gold Card
Posts: 252
Joined: Thu Sep 27, 2018 1:59 am

Re: S/SuperBASIC Arrays

Post by Tinyfpga »

Thank you, janbredenbeek, for your explanation. I had not really given any thought to the memory management required
to support arrays. I understand why the problem of memory fragmentation is problem for large arrays. I assume that if
there wasn't a contiguous block of memory available for an array the program would fail and there would be nothing one
could do about it. As has been suggested, I am going to experiment with large arrays until there is a failure, so that I can better understand the problem.
Is there any way of finding out if there is enough space before trying to create an array?


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: S/SuperBASIC Arrays

Post by tofro »

Well, to kind of put this in proportion a bit: The only (even most modern, contemporary) BASIC implementation I know that supports dynamic arrays is in fact Microsoft Visual Basic - And Visual Basic only supports the very same "rubber array" approach that the Turbo Compiler has had for decades (where the last dimension can be dynamically changed) with the ReDim command.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Tinyfpga
Gold Card
Posts: 252
Joined: Thu Sep 27, 2018 1:59 am

Re: S/SuperBASIC Arrays

Post by Tinyfpga »

In trying to find the program "sysmon" in Dilwyn's website so that I can test the effect of resizing large arrays
on memory I came across some documentation on Things.

Things are described as a "kind of file in RAM that can be accessed by one or more jobs". As files in RAM
are dynamic wouldn't it be possible to create a shareable (or not) Dynamic Array Thing. Going further
might it not be possible to create a shareable database Thing.

tofro writes that of the known Basics only Visual Basic sort-of supports dynamic arrays. Does that imply
dynamic arrays are supported by other high level languages?


Post Reply