16

I'm working on a project in C and it requires memalign(). Really, posix_memalign() would do as well, but darwin/OSX lacks both of them.

What is a good solution to shoehorn-in memalign? I don't understand the licensing for posix-C code if I were to rip off memalign.c and put it in my project- I don't want any viral-type licensing LGPL-ing my whole project.

oz10
  • 153,307
  • 27
  • 93
  • 128
user17925
  • 989
  • 2
  • 10
  • 20

9 Answers9

15

Mac OS X appears to be 16-byte mem aligned.

Quote from the website:

I had a hard time finding a definitive statement on MacOS X memory alignment so I did my own tests. On 10.4/intel, both stack and heap memory is 16 byte aligned. So people porting software can stop looking for memalign() and posix_memalign(). It’s not needed.

oz10
  • 153,307
  • 27
  • 93
  • 128
  • 2
    SSE guarantees this on x86: Malloc has to return a pointer to memory suitably aligned for any type of object, which on x86 includes SSE vectors (which require 16-byte alignment) –  Oct 13 '08 at 00:33
  • 7
    You may want a larger alignment for other reasons. A cache line (potentially 64 byte alignment) is one example of this. – robbie_c Nov 28 '12 at 14:02
  • 4
    Note that OS X *does* have posix_memalign, useful (for example) for aligning to page boundaries or compiling AXV libraries. See http://stackoverflow.com/a/22876707/558639 – fearless_fool Jan 07 '15 at 04:33
13

update: OSX now has posix_memalign()

Late to the party, but newer versions of OSX do have posix_memalign(). You might want this when aligning to page boundaries. For example:

#include <stdlib.h>

char *buffer;
int pagesize;

pagesize = sysconf(_SC_PAGE_SIZE);
if (pagesize == -1) handle_error("sysconf");

if (posix_memalign((void **)&buffer, pagesize, 4 * pagesize) != 0) {
  handle_error("posix_memalign");
}

One thing to note is that, unlike memalign(), posix_memalign() takes **buffer as an argument and returns an integer error code.

fearless_fool
  • 33,645
  • 23
  • 135
  • 217
  • 1
    Thanks! Works for me. I need it because AVX requires 32 byte alignment, not 16 byte. – Bram Jan 05 '15 at 03:32
8

Should be easy enough to do yourself, no? Something like the following (not tested):

void *aligned_malloc( size_t size, int align )
{
    void *mem = malloc( size + (align-1) + sizeof(void*) );

    char *amem = ((char*)mem) + sizeof(void*);
    amem += align - ((uintptr)amem & (align - 1));

    ((void**)amem)[-1] = mem;
    return amem;
}

void aligned_free( void *mem )
{
    free( ((void**)mem)[-1] );
}

(thanks Jonathan Leffler)

Edit: Regarding ripping off another memalign implementation, the problem with that is not licensing. Rather, you'd run into the difficulty that any good memalign implementation will be an integral part of the heap-manager codebase, not simply layered on top of malloc/free. So you'd have serious trouble transplanting it to a different heap-manager, especially when you have no access to it's internals.

Community
  • 1
  • 1
  • 5
    Below the malloc call, you should add `if(!mem) return NULL;`. – Martin B Jan 28 '11 at 13:45
  • 1
    Your implementation of `aligned_free` will segfault if `mem` is `NULL`. From the [man page](https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/malloc.3.html): "If ptr is a NULL pointer, no operation is performed." – robbie_c Nov 28 '12 at 13:24
  • 1
    amem += align - ((uinptr_t)amem & (align - 1)); should be amem += (align - ((uintptr_t)amem & (align - 1)) & (align-1)); The current code will waste align bytes if amem was already properly aligned. (and you'll overflow the returned buffer) – Cholesky Apr 14 '13 at 23:18
  • If align = 1, I think that this code will overflow. – Daniel Lemire Dec 28 '15 at 17:39
3

Why does the software you are porting need memalign() or posix_memalign()? Does it use it for alignments bigger than the 16-byte alignments referenced by austirg?

I see Mike F posted some code - it looks relatively neat, though I think the while loop may be sub-optimal (if the alignment required is 1KB, it could iterate quite a few times).

Doesn't:

amem += align - ((uintptr)amem & (align - 1));

get there in one operation?

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
2

Yes Mac OS X does have 16 Byte memory alignment in the ABI. You should not need to use memalign(). If you memory requirements are a factor of 16 then I would not implement it and maybe just add an assert.

Ted
  • 14,465
  • 6
  • 28
  • 28
2

From the macosx man pages:

The malloc(), calloc(), valloc(), realloc(), and reallocf() functions allocate memory. The allocated memory is aligned such that it can be used for any data type, including AltiVec- and SSE-related types. The free() function frees allocations that were created via the preceding allocation functions.

oz10
  • 153,307
  • 27
  • 93
  • 128
1

If you need an arbitrarily aligned malloc, check out x264's malloc (common/common.c in the git repository), which has a custom memalign for systems without malloc.h. Its extremely trivial code, to the point where I would not even consider it copyrightable, but you should easily be able to implement your own after seeing it.

Of course, if you only need 16-byte alignment, as stated above, its in the OS X ABI.

Dark Shikari
  • 7,941
  • 4
  • 26
  • 38
1

Might be worthwhile suggesting using Doug Lea's malloc in your code. link text

0

Thanks for the help, guys... helped in my case (OpenCascade src/Image/Image_PixMap.cxx, OSX10.5.8 PPC)

Combined with the answers above, this might save someone some digging around or instill hope if not particularly familiar with malloc, etc.:

The rather large project I'm building only had one reference to posix_memalign, and it turns out it was the result of a bunch of preprocessor conditions that didn't include OSX but DID include BORLANDC, which confirms what others suggested about it being safe to use malloc in some cases:

#if defined(_MSC_VER)
 return (TypePtr )_aligned_malloc (theBytesCount, theAlign);
#elif (defined(__GNUC__) && __GNUC__ >= 4 && __GNUC_MINOR__ >= 1)
 return (TypePtr )     _mm_malloc (theBytesCount, theAlign);
#elif defined(__BORLANDC__)
 return (TypePtr ) malloc (theBytesCount);
#else
 void* aPtr;
 if (posix_memalign (&aPtr, theAlign, theBytesCount))
 {
     aPtr = NULL;
 }
 return (TypePtr )aPtr;
#endif

So, it could be as simple as just using malloc, as suggested by others.

e.g. here: moving __BORLANDC__ condition above __GNUC__ and adding APPLE:

#elif (defined(__BORLANDC__) || defined(__APPLE__)) //now above `__GNUC__`

NOTE: I did NOT check that BORLANDC uses 16-byte alignment like someone above stated OS X does. Nor did I verify that PPC OS X does. However, this usage suggests that this alignment isn't particularly important. (Here's hoping it works, and that it could be that easy for you searchers, as well!)

meh
  • 1
  • Your preprocessor directives for `_mm_malloc` looks odd, since `_mm_malloc` is intel only (AFAIK). – malat Feb 26 '15 at 14:25