[Oberon] RE: Input.Time

[Michael A. McGaw]

Hello all:

I too, use NO in real-time applications, and have a two commercial
applications that utilize NO in data acquisition and servo control.  I have
also spent a fair amount of time implementing a version of the task handling
as described by Wirth in his Tasks vs. Threads paper, and see this as a
potentially viable path for those who need pre-emptive facilities, within a
given class (tasks that have no context to preserve across many
activations), using NO as the basis.  This is very attractive, as NO is
impressively powerful, but is compact enough that it can be understood and
modified by one person.  BB appears to follow this philosophy as well, and
this is a major attraction.

I agree with the comments of Dr. Sedlacek, in their entirety: NO and BB
certainly have application to real-time projects.  However, a serious
consideration of which classes of real-time BB may be suited to is
warranted.  The impact of the GC on deterministic system behavior cannot be
underestimated.  I can understand the reasons as to why the current GC
implementations are in use: when NO and BB are used as testbeds for the
trial of concepts and approaches of compiler technology or other
systems-level notions, a _functioning_ GC is sufficient.  It is when we
discuss hard real-time needs that the GC is found to be a significant issue.

I personally can see great application for BB in hard real-time: I can
easily envision applications in which one CPU is loaded very heavily
handling multi-loop servo control and data acquisition.  Another CPU would
be free to offer additional services that are tightly time coordinated with
the first, but that could not be accomodated as background tasks due to
resource utilization.  Now, there is an argument to made that faster CPUs
come all of the time, and one might just wait to use a faster CPU (as the
primary).  The problem is, designers wish always to take advantage of this
performance increase.  Here, the problem is not neccessarily software
largess in the commonly understood sense, but, compact software that
requires increasing compute bandwidth.  Another use for the multitasking (if
not multiprocessing) is in applications in which a given task must be
preemptable, and yet must preserve its state or context.  Here, I am
thinking of (a kind of) binary tree processing that is regularly,
periodically interrupted (e.g., hard deadlines) so that I/O can be performed
based on the tree processing result at that time, and where the state of the
recursion must be preserved.  This latter example is all but impossible to
implement under NO, as far as I have been able to see, but could be easily
done in BB.

I have not studied the internals of BB to know what may be possible, but, I
have considered the following with regard to NO, and its GC:

1. Remove automatic GC, and instead implement the calling of the GC under
user control.  This must be done with care, as some system elements require
calling GC periodically to function properly.
2. Examine the core system for object usage, and redesign, where necessary
and possible, using only statically allocated structures.  Without the
interface handling, the need for dynamic structures diminishes, and, in some
embedded systems, the interface is dispensed with.  This approach leaves the
management of the GC totally at the user's descretion.
3. Remove GC and use Dispose (!)
4. Implement some type of incremental GC, that is bounded (e.g.,
deterministic) in its behavior.

I have done 1, upon occasion.  4. appears to be the most desireable state of
affairs, from my perspective.

I would think that 4. would be a very interesting project, unfortunately, it
is beyond my skill (I am trained in aerospace engineering, not computer
science).  An enterprising student may find this problem an attractive
project, however(!).

Thanks,

Mike

Michael McGaw, Ph.D.
McGaw Technology, Inc.