But then why test for non-aligned limbs? Currently try test for all possible byte alignments! Or at least it is supposed to. I'm still not sure I see what is going wrong with try. To me this is still a puzzle.
I didn't actually look at the assembler yet. I am quite sure it *is* broken, for some suitable definition of broken. But the real question is how can that be? This code passes the tests and most certainly should not! Bill. 2009/12/10 Cactus <rieman...@googlemail.com>: > > > On Dec 10, 3:56 pm, Dan Grayson <d...@math.uiuc.edu> wrote: >> He could also mean that the machine instructions that move 8 byte >> words to vector registers would segfault if you tried to use them on >> nonaligned data, and that he tried to write mpn_lshift to try to avoid >> doing that. Those are the lines of code I pointed to in the original >> report. It would be a bug to write code that depended on alignment, >> as I pointed out, unless you change the documentation about custom >> memory allocators, which should not be done lightly. >> >> On Dec 10, 9:43 am, Bill Hart <goodwillh...@googlemail.com> wrote: >> >> >> >> > I found the following in correspondence with Jason (I can't just ask >> > him, as his internet seems to be offline at the moment): >> >> > "Misaligned data will segfault on some arches and instructions eg K10 >> > and lshift" >> >> > So presumably he has assumed data is aligned on K10, written a fast >> > version of the code for this case, then propagated it to other arches >> > where no segfault will occur. Actually, I am unsure whether that is >> > what he means, but that is what I infer. >> >> > If so, the solution would seem to be to replace the Core2 and Atom >> > code with a safer version and leave the K10 code as is. That's really >> > something Jason should do though, so we probably have to wait for him >> > to pop up again.- Hide quoted text - >> >> - Show quoted text - > > Looking at the code, it seems to me that it has been designed for > doing 16 byte operations that are at least 8 byte aligned. This is > what I would expect in 64-bit assembler code, which an reasonably be > designed to rely on 8-byte alignment. > > Moreover, Jason's code does appear to account for any additional 8- > byte segments are needed at the start or the end of a sequence of 16- > byte aligned operations. > > So it looks to me like a code bug rather than a documentation bug. > > But the Custom Allocation section of tthe manual says nothing at all > about alignment. It doesn't even require that limb allocations are > properly aligned on the target machine - i.e. 4 byte alignment in 32- > bit MPIR and 8 byte alignment in 64-bit MPIR! > > I suspect a lot of the assembler code won't deal well (if at all) with > mis-aligned limbs so we should surely say something about this in the > documentation of Custom Allocation. In my view we should indicate > that use of assembler code is suspect if memory allocation does not > ensure correct limb alignment - i.e. n byte limbs should be at least n > byte aligned. > > 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.
