Comment Re:What Benefit Does C Have Over Assembly? (Score 1) 207
You have some insight, but not into how compilers work, nor how good programmers improve code. It has been a very long time since I wrote any C, but it was writing much of a (non-optimizing) C compiler. It must be said though that one reason I didn't finish it was looking at all the cool ways to optimise
If I were writing/designing a BIOS (which I must admit I am glad I am not) I would also pick C as the "best" language for the job. I'd then write the cleanest possible implementation of the design, using assembler only where absolutely necessary - which would likely be for platform dependent bits in >90% of the cases anyway.
The code need not be fast (as long as it performs), and it need not be tiny. But it needs to be 100% accurate, and sufficiently well documented to be easily readable.
By not using assembler, developer time until now has been relatively low. No premature optimisation has taken place. The next step is profiling, for which a benchmark suite is set up. This suite will ALSO be used to test that alternative implementations return the same results!
In parallel, the BIOS would be used in Virtual Machines; no ROMs need to be created, to get a good picture of how often various functions are called.
On the basis of this, it can be decided where to focus optimisation efforts. The historical target used to be primarily to get size down to 64k, since the 8088/6 booted to F000:FFF0. Assuming this is still a primary issue on many platforms, the first point of call for optimisation is to reduce any "big" functions - like those which use large (lookup) tables as their easiest/cleanest implementation (an obvious example might be the ascii characters in raster format).
Simply writing multiple versions of a routine in a HL language and then profiling may be enough to achieve the desired performance level (IIRC Jon Bentley wrote on this as one of his "Programming Pearls"), but even then an improvement may be possible by going right down to the silicon.
Admittedly it takes people like John Carmack and Michael Abrash to get everything out of it, but if everybody has a week to optimise a 20 line C "inner loop" function for speed, those who can read the produced assembler will do better than those who cannot, and those who can edit it will do even better.
Of course, over 20,000 lines of code, the C expert will manage better in a month, since rather than fixing 4 functions to perfection, they may be fixing 20 to 95%.
One final thing to note: optimising C compilers are known to have occasional bugs in their optimisation. When you are going to eventually write something to a (flash) ROM responsible for booting your computer, that is not an acceptable risk. That means that you don't want to rely purely on an optimising compiler to do your work for you.