The Sinclair QL Forum

Hi per,
Yes, when i wrote for the mags, I tried to keep programs compatible with all platforms. Timing is very important when you use a bare QL...
As for assembler, unfortunately I took the QPC2 route, rather than buying a Q60. That was to get email and internet access.
My programming is more inspiration based than planned professionally. So after getting a program to work, I analyse it over a long period to optimise the code, depending on how much time I have, and if I think the program is worthwhile.
At present I am planning an ARRAY_(a,b,c) function to replace DiM array(a,b). This wil have allocated memory and peek or poke (c=0 or 1) into a stack matrix on each call. I have done this before, but would like to have a general-purpose routine which Quanta might publish.
Steve.

Steve, I presume your project is designed to overcome the word-integer based limits on array indices(?) My main use for arrays/matrices is for Easyptr/WMan [EZP/WM] data structures. It is possible to make one's own routines to overcome these limitations in EZP/WM while still making use of the Pointer Interface [PI], but it can often take up an inordinate chunk of one's SuperBASIC/SBASIC [S*B] program.

It would have been great if long integers [long] had been part of the fabric of S*B from the start, ie as a fourth type together with 16bit int [int or word], floating point numbers [fp] (and double fps - in a standard format!), and strings. Array indices could have been (optionally) long. But thats unlikely ever to be retrofitted, so we'll have to live with what we have (and be content and use solutions like yours when we need to.

I have been researching the possibility of implementing "free" array things (for want of a better term). By this I mean creating or loading arrays somewhere in memory and letting one or multiple S*B programs attach to them as if they were native arrays. This would allow multiple programs to access a single instance of a dataset, for example, or allow for the separation of a program and some of its data.

There are many good reasons for attempting to do something as apparently inane as this, I assure you The only remaining problem I forsee is the chaos that will ensue if someone types a NEW, CLEAR, or in some cases DIM, once such an array has been linked. It seems there is no way to avoid this without tinkering with the OS, which would leave SuperBASIC and Minerva BASIC out in the cold. (They may anyway not be able to cope with free arrays due to their moveability, but this shouldnt be a problem once the program is compiled). The obvious solution seems to be to keep it to myself I havent done any coding on this yet, but have already written a few useful routines for other reasons that I can re-use for this. At present Im trying to figure out a mechanism for SMSQ/E [smsq] to deal with such arrays gracefully: It must detect, and mustnt try to release, the memory taken up by free arrays..

Per

Hi per,
I needed to compile a program that could access a 1200x1207 array under Turbo for transcoding to digital C via libCport.
Tonight I wrote a program using Turbo_sms_code that can access any dimension of 2D floating_point matrix, and it compiles fine on QPC2, set to 128megs.
The only delicate point is to make sure that you deallocate the stack base.
This is just one component of the Travelling Salesman Program I have to optimise to calculate the shortest route around 300 towns...
Regards,
Steve.

Steve, 1200 x 1207 fit in a normal array, unless Im missing something. Why do you need to devise another array implementation.

Per?

Gents,
in the parallel thread on C-porting there is a "sieve" program sample that accesses a linear array of 200000 bytes allocated on the heap. Actually not much of a problem, although it doesn't work with "standard" S*BASIC arrays.

Regards,
Tobias

Hi per,
A 1200x1207 SMSQ/E array won't compile and execute under Turbo, as George Gwilt has confirmed. So I couldn't transcode it into C. Now I have a short routine to assign or retrieve floating point variables from any array from dim_matrix$(1,1) to more than dim_matrix$(1200,1207). Where the upper limit is I have not had the time to find out.
It works perfectly under SMSQ/E with Turbo_sms_code, and executes seamlessly as a demo_task.
Perhaps Quanta will publish it.
Steve.

pjw wrote: I have been researching the possibility of implementing "free" array things (for want of a better term). By this I mean creating or loading arrays somewhere in memory and letting one or multiple S*B programs attach to them as if they were native arrays. This would allow multiple programs to access a single instance of a dataset, for example, or allow for the separation of a program and some of its data.

The only remaining problem I forsee is the chaos that will ensue if someone types a NEW, CLEAR, or in some cases DIM, once such an array has been linked.

Hi Per,
Something like this already exists in the form of the MEM DEVICE. Tasks running on the QL can share data, and they can all read and write the same MEM channel at the same time. The buffers that are allocated to these MEM channels can be either temporary or permanent. There should be no danger of a task closing down a permanent MEM channel. No chaos should occur. You can read about this in DIY VolN MEM_DOC, which was written by Simon Goodwin.
Michael

Hi Emmbee and per,
Quanta will be printing the 2D Matrix$ functions in the next issue. They use LRESPR Turbo_sms_code and basic written in SMSQ/E on QPC2. They set up an allocated stack that can handle arrays of at least 3162x3162 floating point cells. Or more if linear rather than rectangular, ie: 10 million cells. The contents of the cells can therefor be accurate integers up to 9.999999E6. In basic QPC2 can handle 128megs of memory, but not turbo-compiled programs, hence the limits here. Once compiled, the basic will transcode to C for benchmarking. I may even try to transcode it to Assembly code for QLs, but that will be a long-term project.
Being in allocated memory, the matrix$ can be accessed by any job using the functions.
And as always, you can tweak the code as you wish...as it is implemented in a demo...and adapt it to suit your particular needs.
Now I will be able to calculate a circuit around more than 700 towns with the TSP, once the smsq/e basic array(x,y) will have been converted to a matrix$(x,y). The TSP progam will be printed once sorting routines will have been added. Then it will be free for anyone to try better implementations.
Best wishes,
Steve.

Michael, Im aware of MEM, but it wont do the trick, although it, or something similar, might be useful in handling the memory side of things. More likely Ill be using THinGs, The point of the proposed project is to make these shared arrays transparent to S*Basic and any existing toolkits that use or manipulate standard S*Basic arrays. Basically, you can poke the nametable with any location you like for you array data, but when issuing a NEW or CLEAR, the interpreter tries to release the memory, which it assumes is in the variable values area (in the case of QDOS. In smsq it seems to be more complicated) but isnt.

Steve, I dont understand why Turbo has these limitations. QLiberator can use the full 32k indices, memory permitting, that the interpreter allows. Still, there are times when you need more than 32k items in an array, so your project will be useful even when you dont use Turbo.

Per

Per,
Your project goes far furher than MATRIX$ does. Matrix$ only replaces a 2D array. That is enough for most programs, unless I allow the matrix$ to have a name parameter. But I have no time to work on this for six weeks...as I have other hats than hobbyist programmer.
You could modify the core of Matrix$ to adapt it for 3 or 4D arrays.
It has six_byte cells, so you can store floats or integers with it, or even six ASCII CHR§ per cell.
So the sky is the limit for tinkerers...
Regards,
Steve.