Announcement

Collapse
No announcement yet.

Curious as to internal technique in variable string space memory allocation

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Curious as to internal technique in variable string space memory allocation

    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]
    Mike Luther
    [email protected]

  • #2
    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:
    Code:
    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>
    Lance
    mailto:[email protected]

    Comment


    • #3
      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:

      Code:
       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
      Michael Mattias
      Tal Systems Inc. (retired)
      Racine WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        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>
        Lance
        mailto:[email protected]

        Comment

        Working...
        X