In reality it is rarely a problem for applications, as the ISA usually only catches people out for SSE stuff, and then the result is a segfault, which they'll eventually track down. Also, as portable generic C needs to make no assumption about the endianness of the CPU then good C code is rarely written which tries to do unusual things inside full limbs. Only when advanced coders like Dan try this sort of thing do problems sometimes pop up!
I would be much happier documenting this if I could point to an established precedent which justified it. I agree with Dan that the decision to document this shouldn't be taken lightly, though clearly, at the end of the day, we need to do so. I was unaware that the memory allocator on Windows aligned to 16 byte boundaries. That's quite surprising. In a new module in FLINT, I have assumed at least 8 byte boundaries (though I have a "safe" alternative coded which doesn't make this assumption). It is nice to know this code will run on Windows. Bill. 2009/12/10 Cactus <rieman...@googlemail.com>: > > > On Dec 10, 7:09 pm, Bill Hart <goodwillh...@googlemail.com> wrote: >> In fact it seems there is plenty of documentary evidence on the web >> that GMP also expects 8 byte aligned memory locations for 8 byte limb >> arrays. >> >> Apparently some of the gcc optimisations also expect this (an array of >> unsigned longs on a 64 bit machine is assumed to have 8 byte aligned >> addresses - unless it is an array of length 1 which is sometimes >> handled differently), and as the fundamental unit of currency in trade >> for GMP and MPIR is the mp_limb_t * then you can't even guarantee that >> the generic C build will work with non-aligned addresses! > > On Windows any normal memory allocator will return a pointer aligned > to the size of the largest system supported object. Right now, to > cope with 128-bit xmm intrinsics, this alignment is 16 bytes. > > If someone were to use a custom allocator that does not match this > requirement, my guess is that their application would not last very > long. > > Brian > > -- > > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To post to this group, send email to mpir-de...@googlegroups.com. > To unsubscribe from this group, send email to > mpir-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mpir-devel?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
