Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Program refuses to compile
#21
I wrote:
"one ERASE command and the OVERALL array descriptor is gone. Then I can use: SAVE "Contents"DATA MyArray() and the DIM for it is Dim MyArray(0 to 7,0 to 31) as STRING and lets say that the array is 7K long, then the program saves that seven K with the overall array container. Then the container/descriptor is at the base for the array pointers and then comes the array"

Or to make matters simple then just the pure contents are saved, no overall descriptor and no pointers. Just the size of each element in two bytes and the elements themselves. Then upon loading there will be no duplicates than use up memory and then the duplicates have to be eliminated and everything recompacted again. Lot of extra steps and routines than can be done away with.

If the fixed reserved len is ten for each array element then upon saving the computer should compact it so that a three byte element takes five bytes, the len of the element (two bytes) plus the data itself. Upon loading the process should be reversed and that should be taken into account when calculating if there is enough space upon the heap to actually receive the array. To do that then a two byte descriptor should be enough that holds the reserved len and it of course should be checked after loading provided if there is enough space on the heap to load the actual byte file, tape or disk. There should also be another two bytes for the size of the largest element as the heap routines have to have that information to determine the workspace for itself. Other than those four bytes, just the pure element data.

The container/descriptor is at the base for the array pointers and then comes the contents of the array and the data is loaded right after the array pointers.

Then to check the DIM match it checks if there an equal number of pointers set up by the DIM in the loading program and the elements loaded in. To do that it has to count the number of elements loaded in by reading the len of the first two bytes and then jump that len plus two bytes to the next element and add one to a number of elements counter. Then it is a huge help to have the array totally compacted prior to saving it and it saves space.

The next step is connecting the contents of the array to the pointer structure after the array has been expanded according to the reserved length, or to plug it in. To make matters even simpler then the four bytes previously mentioned should be saved at the end of the array contents as it makes clean up unnecessary and the shifting down of the array by four bytes.

To plug in an array as a data stream or stream programming of encapsulating contents in a standalone block.

I wrote:
"Of course, after the bytes header load then there must be a check to see if there is enough space on the heap for it after the computer has compacted it after finding a LOAD"Contents"DATA MyArray command. After the load then it must check if the data matches the overall descriptor set up by DIM in basic by the loading program. Then it must connect the pointers."

The basic pattern here is based on a trinity: Execution (The load command), Order (it's format or the data keyword) and File as in to file something between places to be executed or to file or to fill in the pointer structure, then the plug in execution is complete.
Reply


Messages In This Thread

Forum Jump:


Users browsing this thread: 2 Guest(s)