>
>And that is precisely why it *is* possible to have a compiler do the
following
>
>1. produce code that has processor specific opcodes
>2. produce code that is optimised for different processor architectures
> - both in terms of execution & pipelining units, taking advantage of out
>of order & speculative execution etc.
>3. produce code that can approach the best hand-tuned assembly code
>

I recntly worked onto manually pairing my assembly code, but the timings
were always different on the same processor !
I think this re-pairing can be done efficiently by program.

So, I've recently imagined a source optimiser, something more powerful than
Vtune.
It would take an assembly source and create another source which is
fine-tuned for any 386 processor.

Has it been already done ?
I know it already exists for C and Fortran...

>
>>Regardless of which assembler you use,
>>the code will stay at the exact same speed, as opposed to C compilers,
where
>>it in fact can make a big difference.
>
>Perhaps someone who has access to multiple compilers can prove or disprove
>this. I know many years ago that the Watcom compilers always used to come
>out pretty good. Mu gut instinct tells me that this is probably still the
>case.
>
I have access to a lot of compilers, but the best for Windows at this moment
seems to be Microsoft Visual C++ 6.0.
The latest version includes dead code elimination (thus reducing the final
EXE file, for example, recompiling Prime95 saves around 30 kilobytes of
executable).
And above all, this compiler included all optimisations suggested by Agner
Fog (although floating point generation is still weak).
You can check them at http://agner.org/assem/

Jean-Charles


________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

Reply via email to