On Mon, Apr 19, 1999 at 06:53:08PM -0700, Mersenne Digest wrote:
>And that is precisely why it *is* possible to have a compiler do the following
Yes, a compiler.
Assembly doesn't use a compiler. A compiler changes the C code into assembly
code. The assembler only translates the assembly codes into opcodes. The only
reason processors read opcodes instead of the ASCII text representing
assembler code, is because it's faster and takes less space.
In other words, a single line of C code could translate into as many as 20-30
assembly instructions, possibly even more.
>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
Yes, but that is C code. The reason C code is much more popular than assembly,
is (among other things) that it is portable.
>>In other words, the phrase `recompiling the assembly in a compiler that is
>>PIII/K63 aware' is totally meaningless. There will soon be PIII aware
>>assemblers (for some reason, I belive gas will be one of the first... How
>>strange.), but all they will do is enable the user to use the new opcodes (as
>>well as the more `standard' opcodes, some of which have been around since the
>>8086 (good old days... I had an 8088)).
>Hold on a minute you contradict yourself here, now is it possible or isn't it?
It is not possible. With a `PIII compatible' or `PIII aware' assembler, I mean
that it can emit the new opcodes. BUT NOT AUTOMATICALLY. The programmer will
still have to use and type in the new instructions, but the assembler will
know which bytes to emit. If you try to insert PIII opcodes in an `old'
assembler, it will simply give you an `unknown instruction' error.
>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.
Again, we are talking C code. Everybody have their favourite C compiler,
whether it be MSVC, Borland, Watcom or GCC. Not assembly. Microsoft's assembler
would emit exactly the same code as Borland's. Read the Intel CPU specs once
and see what your instructions are _really_ converted to. Or use your compiler's
`assembly listing' function once.
--- snip ---
>Has it been already done ?
>I know it already exists for C and Fortran...
It's much more difficult to improve existing assembler code than generate new,
efficient one. This is because it's often much more difficult to find out
exactly what the assembly code is trying to do. In addition, there may be side
effects that are not really important for the program, but how do you tell an
optimizer that?
An easier idea (I believe) would be a program that can detect stalls in the
assembly code, and leave it to the programmer to eliminate these stalls.
/* Steinar */
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
