Announcement

Collapse
No announcement yet.

Structures create holes in my tag database layout

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


  • Structures create holes in my tag database layout

    I understand the 'why' for this, does anyone have any thought for mitigating this? Currently, I have made the decision to allocate about 200 extra bits so that I have a buffer between what I need and what structures will allocate so that I do not have holes in my tag database.

    When a structure is created, new tags/systemIDs are allocated. This makes 'holes' in my tag database.
    Ex. Say that I have up to C-000100 and STR-000050 allocated. I create a structure for an RX instruction. This allocates tags/systemIDs for five booleans and one string.
    Now, C-000106 and STR-000052 are the next available SYSIDs.

    Some will say that it doesn't matter and that this is THE WAY that tag-based/structure-enabled dB management programming works, but I would like to try to keep groups of functionally-related tags/systemIDs contiguous.

    Maybe (if this is not an insanely silly idea) structures could allocate systemIDs from the other end of the datatype ranges. <-- This may NOT be a realistic approach.


  • #2
    If you want to create tags in contiguous groups then you need to add them all manually in the configuration you want. Same as how you could/would pre-create them in DirectLogic. Parts of the tradeoff of auto creation and generation of tags is that you dont really get to assign things manually, but one of the other benefits is that you dont need to care as much about where things are stored any longer.

    If you want a contiguous block for data transfer then you could just create a block of tags yourself that are contiguous and before you do a transfer, copy all data from all the randomized tags you need into the contiguous block, then do the transfer. Similar to how GS drivers have a contiguous block of pointers that you use to do a large block transfer when all your parameters are located out of order. If you need to transfer a block of data from somewhere in to the Productivity you can just read it into a continuous set of tags and then do move instructions to move it around where you need to the individual non continuous tags. It is a bit more of a hastle, but it at least allows you to do single large transfers on the network and it keeps a whole block of pre made tags specifically for network data transfers so you know what they are.

    Comment



    • #3
      Originally posted by MikeN View Post
      If you want a contiguous block for data transfer then you could just create a block of tags yourself that are contiguous and before you do a transfer, copy all data from all the randomized tags you need into the contiguous block, then do the transfer.
      That helps some, but not completely. It addresses the impact of contiguous registers on comms transaction efficiency, but now you have to do N moves to get the data from the N places to the contiguous range prior to communicating, so you're still having to do awkward stuff as a result of the memory architecture.

      Comment



      • #4
        Originally posted by kewakl View Post
        When a structure is created, new tags/systemIDs are allocated. This makes 'holes' in my tag database.
        Ex. Say that I have up to C-000100 and STR-000050 allocated. I create a structure for an RX instruction. This allocates tags/systemIDs for five booleans and one string.
        Now, C-000106 and STR-000052 are the next available SYSIDs.
        What do you mean by "allocated" in this context? Used in the program? Docs entered? IOW, what tells DMD that element is used and start the range for the struct at the next free element? Whatever that is, can you simulate that as a way of forcing DMD to use the higher numbered registers? Or, can you create a new data block of the same type (SINTs, UINTs, bits, whatever)? Is there a way to get the struct to use other data blocks of the desired types? Or if not, could you let the structs use the built-in ones and make new ones for your own use in the program?

        Oh, just saw this was about PxK. Never mind, I have no idea what to do there.

        Comment



        • #5
          "Allocated' Just created in tag database - and used in the instruction that caused the creation of the tag/systemID.

          Saw note about DMD-vs-PxK. Thanks for your input anyway!

          Comment

          Working...
          X