Embedded devices have many requirements beyond what is found in desktop computer systems. Top priorities differ for each embedded system, but often include some combination of (sometimes contradictory) needs--needs that are neglected by most script-language vendors.
At Nombas, we recognize scripting as a unique and revolutionary solution to the needs of the embedded device market. Nombas employs a number of technology advances to meet these needs:
- Small memory footprint - The C/C++ and Java versions
of Nombas scripting engines all use minimal execution-image and
run-time memoryusing many techniques such as implicit inheritance,
static function descriptors, and compact structuresas demonstrated
by our small/fast statistics.
C/C++ options allow further selection of small-memory use
versus performance. Finally, the run-time can be built separate
in half of a 64K segmentour WMLScriptEase implementation
is even smaller.
- High-performance - Nombas' virtual-machine byte-codes
are designed to optimize run-time performance, as demonstrated
by our small/fast statistics;
these byte codes are generated by a fast two-pass compile. Compile-time
C/C++ options allow further selection of caching and other
performance options versus small-memory use.
- Robustness and error-recovery - An embedded device may be required to run on and onrebooting is not an option. It is the nature of scripting to be more flexible than low-level languages. For further robustness and error-recovery Nombas' development APIs allow error reporting and cleanup at many levels (function, thread, and interpret), all portions may run in separate threads, API parameter can all be checked at the interface layer, and debug components validate all use of memory.
- Real-time performance - An embedded system must respond in fixed time, whether it be currently within the system-level C or Java code, within the interpretation of script code, or in the interface between the two. For cooperative situations Nombas' script engines return control to your system at every statement level. Access to the script environment is even made safe and available during interrupts.
- Fast, same-context garbage collection - An embedded system
cannot afford to waste memory (even a little waste over time adds
up unacceptably) and so garbage collection is essential. But a
real-time system cannot afford the pauses that are imposed as
traditional sweeping or copying garbage collectors do their dirty
work. The ScriptEase garbage collector is customizable per-thread
and per-context for the needs of the each real-time environment.
- Ease of development - Embedded systems often need to be customized for similar, but not identical, systems. With scripted development the time and cost of these customizations is greatly reduced by a factor of 2 to 60. With the remote debugger interface and IDE, all of the tools traditionally used in a desktop environment are just as easy to use in embedded systems.
- Interaction with other devices, controllers, and components - With multiple devices commonly implementing industry-standard ECMAScript and WMLScript languages, including larger server systems, interaction between these components because magnitudes easier to implement and with fewer bugs. Nombas' Distributed Scripting protocols make this much easier still.
- Low unit cost - When pennies-per-unit can make the difference between market success and failure. Simple licensing models, without additional royalty fees, means that the Nombas engines can be included at a low per-unit cost.
- Processor-vendor independence - You don't want to be
locked into any one chip vendor. The platform-independence of
Nombas' engines, with compile-time
C/C++ options to represent differences in chip behaviors,
you can be assured that your investment in script-enhancing your
embedded system will be portable.
- Low use of stack space - For limitations of some systems, concerns about recursiveness, and requirements of absolute limits on stack growth, Nombas' engines can be called in iterative, non-recursive modes.
- Single vs multi vs cooperative threading options - The contexts in which scripts execute can be run completely independently or cooperatively. Scripts and script segments can run in preemptive separate threads or cooperatively within the same thread, whichever suits the needs of your system.
- Working within I/O limitations - ISDK/C is so portable because it relies on only the most basic C-language features. There is no dependence on standard IO, which is important because many embedded devices have no standard IO.