|Re: C code .vs. Assembly code for Microcontrollers email@example.com (1996-03-25)|
|From:||firstname.lastname@example.org (Mark Hopkins)|
|Date:||25 Mar 1996 21:58:03 -0500|
Though I started out in the assembly camp, I don't believe that either
a HLL or Assembly can achieve as good a result as is possible. The
reasons have been adequately noted by all parties involved.
The third alternative is something that doesn't yet exist: a High
Level Code Generator. Essentially, this is the back end of a compiler
made into a fully programmable and fully user-accessible language
tool. All the code generation and optimization is under your ultimate
control and everything is processed into assembly at "compile-time".
This takes the idea of a macro-assembler an entire generation forward.
Instead of macros, you now have a front-end that is equivalent in
expressive power to the Lambda Calculus. Libraries handle all the
standard conversions and optimizations, you do the rest. So you can
basically have the feel of a high level language with the flexibility
and power of an assembler.
Here's a case in point where the two alternatives fail. On the 8051,
there is an extremely efficient way to implement multitasking
(efficient means: about 20 lines of assembly and a dozen bytes of
memory at most, with little or no context switch needed). However, to
retain that efficiency, the code has to be hand-customized for each
application in highly unpredictable ways and a large set of
constraints have to be simultaneously observed. To try and figure out
all the possibities *in advance* in order to put into a software tool
would amount to nothing less than creating an Expert System. To
continually be doing all the customizations by hand is tiring. To
interface this with an already existing compiler is totally out of the
question. Only a Code Generator can resolve the need in an efficient
manner, where you can implement the appropriate conversions on a
need-to-use basis, instead of *all at once* and do your own upgrades
periodically, instead of hacking someone else's compiler, or waiting
for them to come up with the same idea(s).
Because of the processor's architecture (and this is something largely
shared by other 8 bit processors), it also frequently proves
impossible to create use-for-all-occasions libraries for applications
(e.g. a motor control interface, a A/D interface), because once again
the diversity and unpredictability of actual instances of applications
will invariably break the constraints of any but the most generalized
and hairy library implementation. A dichotomy is raised between
over-designing a library in advance and maybe sticking in a few
parameters that will hopefully placate the masses, or creating new
incarnations with each use. This is a false dichotomy that a Code
So next time the issue of Compiler vs. Assembler comes up in relation
to real-time embedded applications, point out the existence of the 3rd
Return to the
Search the comp.compilers archives again.