On Dec 10, 8:09 pm, Bill Hart <goodwillh...@googlemail.com> wrote: > 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.
I need to be more precise in case you want to rely on this. In Windows x64, malloc and its friends return memory addresses that are 16-byte aligned. This is part of the Windows x64 ABI defined here: http://msdn.microsoft.com/en-us/library/ycsb6wwf%28VS.80%29.aspx In win32 this is NOT true. 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.
