ok, found another line with the same problem - I saw this after seeing
another post reporting also a amd64 issue with emblem and trying to
start emblem myself...
Now, before submiting another patch (emblem actually worked after
changing one more instruction) I just wanted to speculate about the more
general solution to this problem (I'm by no means an assembly expert,
just did some reading on the net and took a better look at the code):
What I think is that the problem with memory alignment resides only in
the lines where data is copied from/to addresses using (RIP) relative
addressing (at least it was the case in the lines that I changed before
and now again).
I mean, the problem is not with the source/destination pointers
(parameters) because the assembly code already checks if these pointers
are aligned and uses the best instruction acording to the case (and sure
the performance drop for coping unaligned memory is really big), the
lines that gave problems where just the ones that use something like
"movdqa 0xXX(%rip),%xmmN";
The question is, there are a lot of other points of the code where a
aligned copy to/from a relative address is made, should all of them be
changed to unaligned or is there another solution?
As said, all of this is just a suposition...
On Mon, 2005-08-22 at 07:45 -0600, Tres Melton wrote:
> On Mon, 2005-08-22 at 07:29 +0000, Tiago Victor Gehring wrote:
> > Hi,
> > regarding the problem I mentionted about the new amd64 optimized
> > functions in imlib2, I think I found the problem, has something to do
> > with the fact that memory was not aligned in some (SSE2 128 bit) MOV
> > operations - ie, I just changed a couple of MOVDQA to MOVDQU in file
> > amd64_blend.S, treating memory as unaligned;
> > Now if this has some other side effects (speed?) I don't know, but for
> > me it worked now...
> >
> > Cheers,
> > Tiago Gehring
> >
> This is a poor solution in terms of speed. The correct solution is to
> ensure that the memory is properly aligned. For the time being it
> should be left that way (I noticed that raster committed the move
> unaligned data change). I have spoken with vapier (briefly) about it
> and am hoping to force the memory to be aligned on 128 bit boundaries.
> This will impact the stack size of the code and a few other things that
> I want to look into before offering a patch. A couple of hints:
>
> SSE instructions should be aligned on 16 byte (128 bit) boundaries.
> MMX instructions should be aligned on 8 byte ( 64 bit) boundaries.
>
> ASM:
> .align 16
>
> C:
> Image * __attribute__ ((aligned (16))) image;
>
> Regards,
> RiverRat
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis.
Instale o discador agora! http://br.acesso.yahoo.com/
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
