Mail Archives: djgpp/1997/03/04/16:36:05
Hello Robert Humphris:
> I know that this is not related to the topic, but it may be something
> that should be
> thought about...
From my point of view isn't the right place to post, but we MUST have these
thing in mind or we will loose ...
> MMX whatever is stands for ( I have heard several versions ) is the
Just go to the intel web and read the pages of they, if you will use a Pentium
is better to take the Intel's version of the name ;-)
> addition to the Pentium
> of some rather natty hardware, in the form of a SIMD parallel processing
> module.
> Single Instruction Multiple Data is basically the cheapest form of
> parallel processing to do,
> it means that multiple values can be processed at the same time, for
> instance:
>
> for( i=0; i<7; i++ )
> {
> array[i] = array[i] ^ 20;
> }
>
> this would take eight iterations in a von Neuman architecture machine
> but only one in a SIMD
> machine ( as long as their is provision to take 8 values as there is in
> the MMX ). The result is huge speed
> up factors when performing tasks such as de/compressing, image
> processing, 3d image manipulation, etc.
Yeap, Intel shows some very favorable cases where the speed-up is just amazyng.
> The question is, will DJGPP need to support this in the future?
Is hard to say, but be sure that GAS must support it (NASM support it if my
information is good).
> I think
> that it will, as the Parallel capability
> of future chips is going to be expanded upon MMX2 is already being
> tested, although what form this will take
> I do not know.
>
> Personal I think that it should be an extra set of C functions that
> provide the support, parallel scheduling,
> and optimization is still the stuff of Doctatorial reseach so I don't
> imagine that we will be seeing '-03SIMD'
> switches on the command line just yet, but I believe that we need to
> address the issue of how a set of
> parallel commands would be indicated ( is there any news from MS,
> Borland, or Watcom as to how they plan
> to do this? they will have had access to the chip for much longer than
> us ). We could go for something
> akin to that of Occam2 where the function : PAR( i=0; i<20; i++ )
> indicates that the next 20 instructions
> are to be performed in parallel.
>
> Your thoughts/comments please
As you said the hard point is the following:
* If you want to use MMX at 100%, you must make one of 2 things:
A) Make a very specialized optimizer, is really hard.
B) Make an extention of the C language, but will be totally non-standard.
The problem is that this tasks belongs to the GNU/FSF group, and they don't
have even a Pentium optimizing facilitie!!!!, and the MMX is 10 times more
complex.
That's very problematic from my point of view.
If somebody makes that in the (B) fashion the best way is the use of
#pragmas but even with that is very hard because the compiler must see the
parallel operations and how to pack it in parallel MMX operations, plus the
fact that Intel is using FPU registers for that ...
Another point to have in mind is that DEC is making your own MMX for the
Alpha line and if some group of persons will make anything will have in mind at
least these 2 implementations.
I guess that in the 2 next years the only thing that you'll see in the GNU
tools is support for MMX assembler.
M$ actually only supports it for MASM and the inline assembler, there are
some links in the Intel's page to M$ and what they say that they are making.
SET
--------------- 0 --------------------------------
Salvador Eduardo Tropea (SET).
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013
- Raw text -