From: bc@freeuk.com   
      
   On 31/10/2025 00:28, Kaz Kylheku wrote:   
   > On 2025-10-30, David Brown  wrote:   
   >> If I were developing a compiler, I would not advertise any kind of   
   >> lines-per-second value.  It is a totally useless metric - as useless as   
   >> measuring developer performance on the lines of code he/she writes per day.   
   >   
   > If that were your only advantage, you'd have to flout it.   
   >   
   > "[[ Our compiler emits lousy code, emits only half the required ISO   
   > diagnostics (and those are all there are), and is compatible with only   
   > 75% of your system's header files, and 80% of the ABI, but ...]] have you   
   > seen the raw speed in lines per second?"   
   >   
      
   How would Turbo C compare then?   
      
   Anyway, C is often used as a target for compilers of other languages.   
      
   There, it should be validated code, and so needs little error checking.   
   It might not even use any headers (my generated C doesn't).   
      
   The main requirement is that after the front-end compiler has generated   
   the C, taking some fraction of a second, it doesn't immediately hit a   
   brick wall if it tried to use a substantial product like gcc for the   
   next stage.   
      
   Here, optimisation is less important (unless the generated is hopelessy   
   poor). But it's quite possible to choose between a fast backend compiler   
   for routine builds, and a slower optimising one for production.   
      
   In fact, you can use this approach anyway even if directly coding in C:   
   use a fast compiler most of the time, and a slower one for a periodic   
   check or when you need the better code.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)