Frank,
        As the designer of the majority of the hardware and all the firmware for
the Flight Control System of the M400 Volantor, I have a unique insight to
the system that you may not be aware of.  First, the original processor
board, (which happens to be one that was designed by my predecessor), is
designed with ceramic DIP EPROMs that provide a maximum of 512K words of
program space.  This is a limitation of the hardware design and will no
doubt be remedied in the next revision of the Flight Control System.  

Now,
granted C compilers have made great strides forward in optimizing the final
assembled code, however in this case we are utilizing the full capacity of
both the memory space and speed optimization of this system.  The assembly
code as it stands now is approaching 20,000 instructions of extremely tight
and fast code.  We are executing 32 bit fixed point optimized mathematical
routines that execute 16 closed loop PID algorithms.  These are math
routines executing Proportional multiplication, Integration & Derivative
functions on each of eight engines to lock-in RPM commands with
re-calculations for all eight done in under 20 milliseconds.  We are also
reading 11 analog channels of flight instrument data including joystick
commands for pitch, roll and yaw; aircraft pitch & roll, attitude; aircraft
pitch, roll & yaw rates; aircraft pitch & roll angular accelerations; engine
temperatures; engine RPMs; and using this data to calculate stability
compensation commands. 

 We are reading compressor temperatures, fuel
pressure, oil level, fuel level, bus voltage, battery voltages and the
states of 32 switches.  We are reading eight throttle position encoders and
one thrust command encoder and commanding eight throttle position servos.
We are reading joystick yaw commands and issuing yaw vane servo commands
using the onboard PWM channels for four yaw servos.  We are communicating
throttle position to eight high-speed 12 bit DACs using the built-in SPI
port, and maintaining full duplex asynchronous command & control
communication with the Pilot Interface & data collection system using the
processor's UART.  There are over 50 system devices that are directly
controlled with SSRs by the Flight Control System.  There is a full error
detection & notification system and the system has the capability to be
flown completely via remote control. 

 The Flight Control System is a dual
system with the Redundant 'B' system operating in parallel with the 'A'
system.  The 'A' and 'B' system are comparing & synchronizing data between
each other.  There are three state machines implemented in firmware to
perform startup, operational and main system status functions.  We are
currently utilizing over 95% of the processor overhead and the firmware has
been fully operational on our test stand without a system crash for over 1.5
years now.  All the firmware has fully re-entrant modules, with a hardware
watchdog implemented and last system state non-volatile memory to allow the
system to recover from a software crash, if there were to be one, within 15
milliseconds and the capability to auto switch to the backup system if that
function is so desired and selected.  Along with all that, the system also
collects real-time data on all the sensors every 11 miliseconds with the
capacity to collect up to 60 seconds worth of data in internal non-volatile
RAM.

        Now with all that being said, I think you may see why we chose to use
assembly.  My experience with the Whitesmiths C compiler that we had
in-house was that it made extensive use of the stack, doing a lot of pushing
& popping to maintain memory integrity and to prevent different modules from
stomping on other module's memory space.  I found that I could write code
that uses roughly 10 times less instructions to perform the same operations.
Discounting the speed issues, we would have run out of program memory space
long before we could have implemented even half of the functions listed
above.  On top of that, I have been able to implement a lookup table in ROM
that makes my math routines run 10 times faster and still have program space
left for new functions.  I have exact control of every function built into
the hardware.

        Your argument about the average C programmer vs the average assembly
programmer just doesn't apply here.  It might hold true if you have plenty
of memory, plenty of clock speed and your feet are being held to the fire to
produce product for release to the sales department.  In our case we have a
limited budget, limited memory, limited processor clock speed and an
extremely exacting environment that leaves no room for error.  This is not
an arcade game, but an aircraft that must be as reliable as possible.  The
firmware has undergone extensive and very rigorous testing and is continuing
to be tested, so I am extremely confident that it is very bug-free.
Virtually every line of code in the system is executed in less than five
hundred milliseconds and I believe the code is solid.

        Granted, as more and more horsepower and memory are available and languages
such as EC (embedded C) and embedded Linux are improved your case will
become more valid.  However I believe there will always be a place for
assembly in an optimized system.  Remember, when you're talking assembly,
you are talking in the microprocessor's native language, and that will never
disappear.  Sometimes just throwing more horsepower & memory at a project
may not be cost effective, and you are also introducing more hardware that
can just as easily fail as the software.  Another thing for consideration is
the fact that as this excess capacity becomes available, I believe newer
programmers become lazy and have no incentive to optimize their software,
witness the bloatware provided by Msoft.  Inevitably, as Intel provides more
clocks and faster RAM, Msoft manages to hog the new memory and burn up the
extra clocks with their next version.

        I have 20 years of experience with assembly and also program in Pascal,
Fortran, Basic, VB, C, C++ and for embedded applications I find that nothing
beats assembly for speed, compactness and precision control.  I've
programmed so much assembly that I think in Op-codes, hex and binary.
        I hope this explanation puts your argument to bed, at least for this
particular application.

Phil Wiggins, Electronics Department
Moller International, Inc.