On 2001-01-29 20:02, Daniel Jungmann <DSJ### [at] gmxnet> wrote:
>> new features like 3D!Now which would be problematic for portability
>> reasons.
>
>Every new AMD & Intel processor supports SIMD instructions ( SIMD =
>single instruction multible data, e. g. 3D!Now or SSE ) and if the
>processor doesn't supports this you must not use them. For example
>if you have an Pentium II which doesn't have 3D!Now or SSE then
>the programm ( PovRay ) don't let you render the scene with single
>precision. I know this looks like a lot of work, but I don't think
>so. I did not need 30h to convert most of the colour calculation of
>PovRay from "normal" to 3D!Now. I would do the "fast" version for
>3D!Now, 3D!NowEx, SSE and SSE2 alone, that is no problem for me. And
>the support is no OS problem, just the processor must support the
>instruction

It is also a compiler problem. You didn't say which compiler you used or
how you got it to produce 3D!Now code. Essentially there are 3
possibilities:

1) You have a compiler which can generate 3D!Code out of "natural" C
    code. This is the ideal case. The same code can be used for 3D!Now
    platforms and for others.

2) You have a compiler which can generate 3D!Now code, if the C code
   follows a certain pattern. This lets you still write portable C code,
   but it may be arranged unintuitively and therefore hard to maintain
   and even slower than the "natural" code on other platforms.

3) You used inline assembly. This is very compiler specific. gcc
    definitely uses a different syntax than VC++, and what I remember 
    from my DOS programming days, there were differences between MS C
    and Borland C, too. This means a lot of code duplication: Not only
    for different processor types, but for different compilers, too.

    So, just to maintain the 4 types of SIMD instructions you mentioned,
    on the main Intel platforms, you may have to maintain 9 or 13
    versions of the same code! And not only you have to maintain it, but
    everybody else who wants to change anything in the affected code.
    Unless this is very localized, the chances that somebody who wants
    to implement a new pattern or media type, has to worry about some
    assembler code he can't even read, seem high to me.

    	hp

-- 
   _  | Peter J. Holzer    | All Linux applications run on Solaris,
|_|_) | Sysadmin WSR       | which is our implementation of Linux.
| |   | hjp### [at] wsracat      | 
__/   | http://www.hjp.at/ |	-- Scott McNealy, Dec. 2000

Post a reply to this message