[<<][staapl][>>][..]
Sun Sep 30 19:25:53 CEST 2007

deleted from brood.tex


Some important assumptions I'm making to support the current solution
are that code updates need to be made \emph{while running}, and that
the target is severely \emph{resource constrained} such that all
compilation and linking needs to be done off--target. This excludes
\emph{late binding} of most code.

Another assumption I'm making is that some binary code on the target
will never be replaced, and will drift out of sync with the evolution
of the language in which it was written. An example of this is a
\emph{boot loader}. Such code needs to be viewed as a black box.

This approach violates transparency.

To give this section some context, I have to make my \emph{beliefs}
more explicit. I believe that a compiler is best implemented using
pure functional programming, because it is in essence a
\emph{function} mapping a source tree to a binary representation of
it. This idea is easily extended with \emph{bottom up} programming,
where part of the source tree generates a compiler to compile other
parts of the source tree. In order to make this work, I believe you
need \emph{transparency}. By this I mean that all \emph{reflection}
(compiler compilation) is \emph{unrolled} into a directed acyclic
graph representing a code dependency tree.

On the other hand, I believe that a microcontroller is best modeled as
a \emph{persistent} data structure. A microcontroller is a
\emph{physical object}, and should be modeled as such,
\emph{independent} of the compiler that is used to create the code
comprising the object state. This is what makes Forth interesting: the
ability to \emph{incrementally update} without having to recompile
everything. Due to limited hardware support (flash ROM is not RAM),
\emph{late binding} becomes problematic, and also induces a
significant performance penalty. This makes \emph{early binding} a
reasonable alternative: in the end the objective is to at least
provide the possibility to write efficient code at the lowest level of
the target language tower.

This is the heart of the paradigm conflict. Where do I switch from a
transparent language tower to \emph{dangerous} manually guided
incremental updates? Maybe the question to answer would be: why does
one want to have this kind of low--level control anyway? The real
answer is that at this moment, I don't really know how to create a
transparent system. The real reason for that is that I've been locked
in a certain paradigm.

Let's explore what would happen if we lean towards any of the two
extremes. If the whole system were transparent, the controller code
would need to be treated as a filesystem if incremental updates were
still to be used. After code changes, one could simply recompile,
relink and upload only the parts that changed. This is the sanest
thing to do.



[Reply][About]
[<<][staapl][>>][..]