[fpc-devel] Aligned dynamic arrays / Maybe implement in mem-mgr?

[Martin Frb]

On 29/03/2019 17:53, Ryan Joseph wrote:
> First minor snag, fpc_dynarray_insert, fpc_dynarray_concat can allocate new arrays like SetLength can. Do we need to make aligned variants for these also? Using array + operators there is no possibility to set alignment.
>
> 1) ignore the problem
> 2) make extra syntax like:
>
> 	a: array of integer; alignment = 64;
>
> 3) make another function to allocate an empty array that sets alignment
>
> 	SetAlignment(a, 64);
> 4) for insert/concat make variants like InsertAligned() and ignore + operators for aligned arrays
>

Question: Should the alignment be "user data" or "type info".
Does it need to be determined at runtime, and set to different values 
(for the same type/variable) at runtime?

If not, i.e. if a specific variable always needs 4k alignment, would it 
not be more logical to make it part of the type?
    type TFoo = array [x..y] of byte aligned 4096;

Of course that does not change the above problem.
The (current or fixed) alignment needs to be stored, so concat can 
retrieve it and honour it.
Stored either in the header or the RTTI type info



Question 2:
Would it not be more efficient, if the alignment would happen in the 
memory manager?
Then no over-allocation would be needed. And the memory that is skipped 
in front of the array could be used for other data.

The memory manager would need 2 new methods:
AllocMemAtAllignment
FreeMemWithAllignment

So the array still needs to know, it was allocated with Allignment and 
call the correct  FreeMemWithAllignment.
As a default for all memory manager AllocMemAtAllignment could do the 
over-allocate, and return the correct pointer, with the mem-managers 
align header.
Individual MemManagers can then be optimized.

pseudo code for AllocMemAtAllignment
   mem := alloc(size+align+sizeof(MemMgrAlignHeader))
   result := getNextAlignedAddr(mem+sizeof(MemMgrAlignHeader))
   (result-sizeof(MemMgrAlignHeader)) ^.RealAllocAddr := mem;

The result looks then like
   mem
      // padding
   result - header:
      RealAllocAddr
   result
     // At least size bytes

So pretty much what would have happened in the array code. But moved to 
the mem-manager.
So it can be:
a) re-used for other types or even called by usercode
b) a mem-manager that can get the aligned address without padding, can 
be optimized, and return a normal block of memory
   (does not even need the MemMgrAlignHeader)