> On Mar 30, 2019, at 5:02 PM, Jonas Maebe <jo...@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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
