[fpc-devel] Aligned dynamic arrays

[Ryan Joseph]

> On Mar 30, 2019, at 5:02 PM, Jonas Maebe <jonas at freepascal.org> wrote:
> 
> How is this done in the Metal C headers?

Looking this now it appears the padding may be put in the actual vector. Maybe those macros put it in there? The fields of the struct need to be aligned on 16 bytes (4 floats) so. Does c++ even allow padding struct fields or is this kind of fringe usage? I thought the compiler already did this so it could just add more?

typedef struct
{
    // Positions in pixel space
    // (e.g. a value of 100 indicates 100 pixels from the center)
    vector_float2 position;

    // Floating-point RGBA colors
    vector_float4 color;
} AAPLVertex;

typedef simd_float2 vector_float2;

/*! @abstract A vector of two 32-bit floating-point numbers.
 *  @description In C++ and Metal, this type is also available as
 *  simd::float2. The alignment of this type is greater than the alignment
 *  of float; if you need to operate on data buffers that may not be
 *  suitably aligned, you should access them using simd_packed_float2
 *  instead.                                                                  */
typedef __attribute__((__ext_vector_type__(2))) float simd_float2;

/*! @abstract A vector of four 32-bit floating-point numbers.
 *  @description In C++ and Metal, this type is also available as
 *  simd::float4. The alignment of this type is greater than the alignment
 *  of float; if you need to operate on data buffers that may not be
 *  suitably aligned, you should access them using simd_packed_float4
 *  instead.                                                                  */
typedef __attribute__((__ext_vector_type__(4))) float simd_float4;

> 
>> If you saw the original bug report we’re trying to make a custom alignment (of 4k) for the Metal framework. I propose the syntax because it solves the problem of how to assign alignment and there is a precedent for it (i.e. $align).
> 
> No, I missed that. In that case, a vector type won't help. The best way then is, as has been mentioned elsewhere in this thread, a getmem variant that supports allocating memory on an aligned boundary. Similar to how unix platforms have posix_memalign.
> 
> This falls outside the scope of direct support in the language, so a solution like Anthony's is better in this case if you want to encapsulate it completely.

I already started on it before I hit the snag and it’s not an unreasonably intrusive thing to allocate the extra padding like I discussed earlier, but it would probably require introducing a compiler directive (see $dynarrayalign below) and adding alignment information to tarraydef. I’ll post what I finished on GitHub if anyone wants to see how invasive the changes are.

There’s a good argument both ways and I guess it comes down to maintaining the extra complexity in the compiler. I’m personally happy to use the record since it’s feasible in 3.1.1 but I understand users who like the compiler syntax, which is cleaner and probably faster.

So what should I do going forward? Should I abandon the idea or do any of the other core team members want to me pursue this further?

{$push}
{$dynarrayalign 4096}
type
	TIntArray = array of integer;
{$pop}


Regards,
	Ryan Joseph