On Tue, 2005-06-14 at 22:50 -0500, Edward Presutti wrote:
> Is it possible to enable Eterm's SSE2 support on P4 class processors? I've
> got a Northwood class P4 3.2 w/ SSE2, but the new makefile looks for
> X86_64 architecture to determine whether or not to enable SSE2. Is this
> patch specific to the X86_64 architecture or will it work on P4 class
> processors?
>
> Thanks,
> Ed
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
> -------------------------------------------------------
> 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_id=7477&alloc_id=16492&op=click
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Tres
-------------------------------------------------------
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_id=7477&alloc_id=16492&op=click
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
