Curious as to internal technique in variable string space memory allocation

[Mike Luther]

An idle thought just crossed my mind.

If it's deemed proper to comment on the PB internal design, would
it be possible to reveal that the memory allocation for string space
always falls out on four byte boundaries or not?

In other words, I have a variable length string for say "Moo", which
is three bytes. Irrespective of whether we allocate minumum, a given
maximum, temporary or otherwise, for string space use, does the actual
use of memory space for all the string handling work always fall out
on four byte boundaries?

What about fixed length strings, as in those we might use inside of
UDT's? Life in my world has calmed down a lot as to things that go
bump by making sure that all the UDT's fall out on 4 byte boundaries!
But hocus pocus being what it is, some of this superstition would be
seem made useless, if, for example, defining COW AS STRING * 3, acutally
produces one silent byte when COW goes "Moo"! That especially next
to the fence when the cow that is 'mooing' might want to jump into the
next EMS 16K or whatever size fence the MB bull fences off in search of
some more enjoyable expanded or extended pasture to "Moo" in!






------------------
Mike Luther
[email protected]

[Lance Edmonds]

Using dword-alignment is wise move (where possible anyway) since it generally leads to more efficient code.

All arrays of data types with fixed-length data members are butted up against each other without any additional padding. You can test this yourself:

dim x(1:2) as string * 9
x(1) = string$(10,65)
x(2) = string$(10,66)
def seg = varseg(x(1))
print chr$(34) peek$(varptr(x(1)),18) chr$(34)
def seg

For scalar (non-array types), then the actual storage will be padded to assist with [dword?] alignment (and hence performance).

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Michael Mattias]

IIRC, the PB string descriptor is 4 bytes big, which means every string actually uses 4 bytes+(actual length of data).

..except...

..the data space for dynamic strings is allocated in multiples of the $STRING metastatment; those segments will always begin on a paragraph (16-byte) boundary.

I have no clue how the alignment works within the allocated data segments, but it really doesn't matter, because once the string segment is allocated, it's allocated in its entirety.

But even at that, "how" the actual strings are located within the $STRING segments is likely considered highly proprietary.

You could test by doing an allocation of multiple one-byte dynamic strings and checking the STRPTR (not VARPTR) values to see if they increase by one, two or four. Just make sure you allocate the string HANDLES (descriptors) first:

 REDIM  X (10) AS STRING   ' allocate eleven string handles
 FOR I = 0 to 10
   X(I) = "X"              ' use up one byte of data space.
   PRINT I, STRPTR(X(I))
 NEXT

MCM

[Lance Edmonds]

Yes, the PowerBASIC/DOS string engine is highly proprietary.

If you are interested in alignment from the perspective that you expect dynamic strings to be stored in a sequential format in memory, then you might be disappointed.

Briefly, when dynamic strings are [re]allocated they are fitted into the first space available in the allocated string segments. Therefore, where the dynamic string data actually resides will depend on lots of factors, including whether there are "holes" available in an existing string segment, whether a new string segment needs to be allocated, etc.

Padding/alignment issues figure in this algorithm too, naturally.



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>