🚀 go-pugleaf

In article <1990Nov15.160222.23856@maytag.waterloo.edu> himacdon@maytag.uwaterloo.ca (Hamish Macdonald) writes:
   >>>>> In article <CEDMAN.90Nov14193209@lynx.ps.uci.edu>,
   >>>>> cedman@golem.ps.uci.edu (Carl Edman) writes:

   Carl> And now using assembler is a "big no-no" ? What is the world coming to ?

   Today's CPUs are becoming more and more complicated, making it more
   difficult to write correct assembler code (especially RISC CPUs, or a
   multiprocessor environment, or a combination of the two).

   Of course, the compiler writers have similar problems in ensuring that
   the code their compilers generate is correct, but at least that is
   done in only one place, not in every program you write (I know, I
   know, it is difficult if not impossible to _prove_ that a compiler
   generates correct code in all instances...)

   In any case, compilation by a C compiler followed either by
   hand-optimization of the assembly code generated (if any), or by going
   back to the code and re-coding inefficient-generated or most-used
   sections should get you both the fast-development time and the program
   performance you require.

I absolutely agree. This is the way I've been doing it since many
years. If you've got a good C compiler then programming much of the
"driving" software in C is excuseable, and maybe even the users
benefit from having a better program. You can get 90% of the speed
by in the end "down-coding" the critical portions (tight loops a.s.o.).

What I really objected to was the idea that if some group of idealistic
and very good programmers actually goes to such lengths to produce the
optimal code for their users , this is called a "big no-no".

        Carl Edman



Theorectical Physicist,N.:A physicist whose  | Send mail
existence is postulated, to make the numbers |  to
balance but who is never actually observed   | cedman@golem.ps.uci.edu
in the laboratory.                           | edmanc@uciph0.ps.uci.edu