Archived from groups: alt.comp.periphs.mainboard.asus (
More info?)
In article <c67r5h$8vg0r$1@ID-57815.news.uni-berlin.de>, "Kylesb"
<me@privacy.net> wrote:
> "Paul" <nospam@needed.com> wrote in message
> news:nospam-2104041825570001@192.168.1.177...
> <snip>|
> | BTW: The comment about "random instruction sequences" refers
> | to the difference between sequences of instructions emitted
> | by compilers, versus those that a human can craft by hand.
> | Compilers don't emit code that exercises even a fraction
> | of the whole instruction set, and there will be plenty of
> | branches and loads mixed into code sequences. A human,
> | on the other hand, could put 20 floating point instructions,
> | one after another, which would do a great job of heating up
> | the FPU block etc.
> |
> | Paul
>
>
> Although I think your comments are generally top notch Paul, I believe
> all compilers emit code that includes a fraction of the whole
> instruction set.
Sorry for my English
My observation is based on a little "looking under the hood"
I did years ago. I'm a hardware guy, so take the comments with
a grain of salt.
I think at the time I was writing a simulator, and had noticed
a big difference between the code being produced by a commercial
compiler and the code coming from GCC. I looked at the intermediate
file that GCC produces, and it seemed to generate a "pseudo code"
for the assembler that was very RISC-like, on a CISC platform.
If I looked in the code, there weren't any complex table
indexing instructions being used, there were discrete address
calculations being done and so on. Maybe 1/3rd of the instruction
set was being used in the code I looked at - hard to say for
sure.
I didn't do a frequency analysis, to see what instructions were
being used what percentage of the time, but it seemed in that
case, that the compiler wasn't using any strategy of finding
the "best instruction for the job" while generating code.
(Not that I expect a human could write such a compiler anyway.)
My second piece of evidence, was an errata issued for a processor
that was in production. In the lab, the designers of the processor
discovered that if certain sequences of floating point instructions
were used, noise in the FPU portion of the chip corrupted the
computed results (that is, switching noise upsetting the Vcore
local to the gates in that section of the chip). The manufacturer
noted that "no compiler will generate this sequence" and as a
result, no fix was created for the bug in later steppings of the
processor. This again implies that manufacturers make certain
simplifying assumptions about what the code that runs on the
processor looks like, and don't necessarily guarantee every
pathological instruction sequence - a fact I find scary, as all
it would take is one "assembler kook" to break the thing.
HTH,
Paul
"assembler kook" - a person who is convinced he can write
better code than a compiler, and will produce a 6" thick
undecipherable uncommented assembler program listing to
prove it