Whether they be new functions or just an optional parameter, I do agree
that they should be compatible with FreeMem rather than requiring their
own function - Microsoft's non-portable _aligned_malloc requires calling
a specialised 'free' function, but the C11 and C++17 standards, despite
having new functions, can use 'free' without any problems.
My impression is that the alignment of GetMem is implementation-specific
and is fine for most applications. On x86_64 at least, it seems to be
at least 16 bytes, but there are some cases where you want 32 bytes
(256-bit AVX), 64 bytes (AVX512) or 4,096 bytes (memory paging).
Gareth aka. Kit
On 22/04/2020 11:07, Michael Van Canneyt wrote:
On Wed, 22 Apr 2020, Tomas Hajny wrote:
On 2020-04-21 20:47, J. Gareth Moreton wrote:
Hi,
As I mentioned in my future development post,
do you think FPC could benefit from
GetMemAligned and ReallocMemAligned routines?
The internal functions could be used to help
control such custom alignment in dynamic
arrays.
Wouldn't it be better to use either some kind of global property or
an optional additional argument than completely new routines
requiring explicit handling not only from the end-user programs, but
also from all units which may in turn be involved in memory
allocation (including various containers etc.)?
I think so too.
What's more, I thought the memory allocation routines already
guarantee some
form of alignment, simply because of the internal structures used by
the memory
manager ?
Michael.
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
