-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 22:29, Tue 14 Jun 05, Tres Melton wrote:
> From: Tres Melton <[EMAIL PROTECTED]>
> To: Edward Presutti <[EMAIL PROTECTED]>
> Cc: Enlightenment/Eterm Developers List
> <enlightenment-devel@lists.sourceforge.net>
> Date: Tue, 14 Jun 2005 22:29:57 -0600
> Subject: Re: [E-devel] Re: Patches to Eterm
>
> As the author of those patches I can tell you that the problem is in
> two places. The first is the MMX/SSE instructions and those will work
> on whichever processor supports them. The second set of issues are
> things like loop control, pointers, and function parameters.
>
> The original author of the MMX stuff, Willem Jan Monsuwe, wrote the
> entire thing in assembly specifically for x86 which annoyed me, a proud
> owner of an AMD64, enough to port the routines to x86-64. In the
> processes of porting I decided to use the extra 64bits in the xmm
> registers that are present in SSE. That was actually the easy part.
> The harder part was porting the surrounding control to x86-64 so the
> short answer to your question is an unfortunate no. I think that some
> of the newer P4s are actually 64 bit, or EM64T, and those processors
> should work as I took care not to use functions or registers unique to
> AMD64 but the control structures are definitely designed for a 64 bit
> processor.
>
> If you are interested in getting the SSE stuff to work with a 32 bit
> processor with SSE2 I'd actually suggest that you start with the MMX
> routines, mmx_cmod.S, and add the few changes that were made to the SIMD
> instructions. They are relatively few and revolve around reading twice
> the data in, writing twice the data out, and adjusting the counters to
> notice that they now handling twice the pixels per pass as the original
> MMX routines did. There are also a few places that have to duplicate
> the colormodifiers in the lower 64 bits into the upper 64 bits too. The
> sse_cmod.c file is actually inline assembly instead of pure assembly but
> it should be easy enough to compare the two and extract the stuff
> relevant to SSE and add them to the mmx_cmod.S file. My reasons for
> moving to inline assembly are detailed in the comments at the top of
> sse_cmod.c I'd also suggest that you ask Mr. Jennings, Eterm's
> author/maintainer, about his feelings since I know he wasn't overly
> enthusiastic about adding another code base to maintain to his
> considerable workload. When I started I tried to make the port using a
> series of #ifdef's but that quickly became overwhelming as the resulting
> code had more preprocessor code than C code. It should be easy enough
> to understand what is going on in my code as it is excessively
> commented.
>
> Good Luck and I hope that helps,
> The RiverRat
Dude I just have to say that I am constantly impressed with your patches, not to
mention your willingness to respond and write out emails addressing your code.
Good documentation is like a breath of fresh air. Please keep up the great work,
and thanks for the free software ^_^.
Stephen
- --
<------------- 悟 Apó Mechanís Theós ------------------->
.-. Stephen Horner void.engineer(at)unix.net
/v\ AIM beepbeepkaah
// \\ MSN parse3rr0r(at)hotmail.com
/( )\ PGP 0xCDC2DD2B
^^-^^ <----------------------------------------------------->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCr9ClRRkTWiD8QjIRAtloAJ0fc2DAvhWh7VHBAOk2UEo3hE2lPwCg4jwP
QVj07qypzSULHfMRzvJkxBI=
=57u8
-----END PGP SIGNATURE-----
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
