sje wrote:I wonder how much one gives up in speed
for the simple fact of it being a C interpretation.
It never struck me as the most efficient language.
Although Brian Kernighan and Dennis Ritchie deny this, I am not
too sure that on the same hardware, a simple assembly language
program wouldn't trounce the equivalent algorithm
implemented in C, despite whatever that algorithm
might be..... chess, cryptography, anything similarly
compute intensive.
I guess that for 999 out of 1000 assembly programmers, the C compiler does a better job of optimizing the algorithm instructions into assembly than the assembly programmer would. Take some simple algorithm like some bitboard operations or an insertion sort loop and compile it at the highest optimization settings with assembly generation. You will be amazed at the clever things that optimizing compilers will do now to generate excellent assembly language.
C is close enough to the hardware that for the most part, it is just a portable assembler anyway. And the real benefit of C is that when the instruction set changes, the algorithm will instantly be translated into the new instruction set. I think it is a big mistake to code an entire chess program in assembly (though little bits of it are fine). I have written plenty of assembly and most of it is useless now, because registers are no longer 16 bits wide (I wrote most of my assembly in the early 1980's).
MOV AX,[BP+08]
would now be:
MOV EAX,[EBP+08]
and soon we would be doing stuff like:
MOV RAX,1122334455667788H
So what would become of our megabytes of old assembly code?
Even having said all that, there is clearly a time and a place to slap in a little assembly here and there. For those few little hot spots that need a touch of grease.