On 28/03/2019 00:43, Ryan Joseph wrote:
I would like to attempt to implement this feature request
(https://bugs.freepascal.org/view.php?id=34031 for my boss) which has the
SetLength intrinsic return aligned memory. We need this for the Metal framework
which requires all vertex buffer memory to aligned on 4k boundaries so we can’t
use dynamic arrays in their current form (see the bug report for example code).
I’ve looked at the dynamic array implementation (dynarr.inc) and it appears
that I could over allocate and extend the header (tdynarray) to include an
extra field which stores the amount of padding until the actual array elements
start (which is aligned). It would complicit the code to some extent however
because the current design relies on lots of pointer math.
Is this ok that I add this? Marco said in the comments there was a need so I
assume this is a go but I wanted to ask first.
2 Ideas, well 1 Idea, 1comment...
The Idea:
Would it not be easier to:
- allocate mem, with extra space for align, unless memmanager can handle
align.
- return the alligned pointer for the array, so all array ops will work
exactly as they currently do
- prefix/extend the array header by a field "OffsetToMemAlloc" (that is
the reverse, of what I understand your padding would do, but still can
be a positive number, the code knows to subtract it where needed)
This field would allow to correctly get the memory for re-alloc/free
operations.
The comment:
As for extending the array header, maybe introduce a new data type
"aligned array".
So normal arrays do not have that field in there header.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
