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)
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
