Pioneering Techniques For Supporting ScriptEase Across
Multiple Mobile Devices
Complex Problem Domain
who have become accustomed to the vast processing power
and seemingly unlimited memory on desktop PCs and servers
have a rude awakening when they start developing applications
for mobile devices, such as Palm, Blackberry, PocketPC,
and EPOC systems. These small handheld and wireless
devices have severe technical constraints, both in terms
of limited heap space and slow processor speeds. Additionally,
each of these devices has different chipsets, processor
capabilities, and hardware requirements, making a solution
for a given device a highly customized one. As a result,
trying to create a solution that works across devices
is extremely difficult to accomplish.
the surface, the ability for a single script engine
to provide support across all of these devices sounds
unreasonable, if not impossible. But, at Nombas, we
have developed a set of ground-breaking techniques that
overcome these technical barriers in a single base of
ScriptEase Integrated SDK is unmatched by any other
vendor in the marketplace.
With Maximized Performance
couples a "microsized" footprint with high
performance by using several innovative techniques:
Object Expansions. Standard objects are only
expanded as needed. For example, in many real world
situations, the complete ECMA library is not fully utilized,
so we do not expand most ECMA objects unless they are
actually used in your code.
Optimizations. By using the minimized memory
build (MIN_MEMORY) option, you can remove performance-based
fields of an object to minimize overhead. As a result,
the C structure of any object can get down to just 15
API. The ScriptEase Version 5 offers a ground-breaking
API that encapsulates much of the complexity and error-handling
for the developer. Data interchange is handled in a
single statement, and virtually all error-handling is
automatically taken care of by the engine. As a result,
very few lines of code are needed to accomplish the
most commonly performed tasks, resulting in little ROM
being required (and fewer chances for bugs). In contrast,
most other script engine API's require several lines
of code to setup and take down structures and check
for error conditions.
Script languages are well known for their extensive
use and manipulation of strings. Therefore, overall
performance and memory use of a script engine is greatly
impacted by minimizing the number of allocations and
the amount of data moved for string allocations.
employ a multitude of techniques for minimizing memory
use and copying strings. Through use of hashing, compression,
and pooling procedures, over half of the identifiers
and strings in a typical script execution never require
Run-time Engine. The run-time part of the ScriptEase
engine may be separated from the compiler portion, allowing
you to run just the run-time segment on the small device.
In many mobile applications, a device will work in combination
with a larger server. In these situations, if the compilation
occurs on the server, then the optimized client code
saves ROM memory on the device, perhaps dropping from
110K to 80K.
Compile-time Options. All ECMA libraries and
or deselected at compile-time. The ScriptEase developer
can then choose to remove options, even ones that are
part of the ECMAScript standard, if their additional
overhead is too large. Moreover, you can turn off entire
objects, such as RegExp or Date, and even individual
methods within an object.
second area of technical hurdles that must be overcome
when developing for a wide range of mobile systems is
the disparate, unique needs of each device. Wireless
and handheld machines are built with different chipsets,
have different processor capabilities, and have divergent
hardware requirements. Our ScriptEase engine is able
to support all of these platforms with a single base
of code using the following techniques:
Processor and OS Requirements. Processor and
OS requirements are defined in a small number of centralized
parts of the ScriptEase source code. We use a common
set of macros to account for minimal code differences
and then allow developers to compile the same source,
but optimized for the target processor and OS.
Extension Layer. To manage the disparate memory
requirements of device systems, all memory allocations
go through redefinable interfaces. The most-frequently
used memory operations are further macroized into a
memory-extension layer (memext) that can be mapped to
the needs of each device platform:
Palm and other devices with small heap but larger
long-term or database memory, memext can be mapped
to a caching system.
EPOC devices that commonly need to compact memory
frequently, memext can allow all but a few in-use
items to move.
devices that distinguish read-only from writable
memory, memext can use the type needed for the item
also handles situations in which memory limitations
require overlaying of functions from disk.
when memext is redefined for a particular device,
the rest of the engine maps to optimized memory-handling
code for that specific device.
Optimizations. Mobile devices have divergent
floating-point capabilities, and individual applications
running on these small systems will have unique needs.
For example, some devices do not provide floating-point
support at all, while some support floating-point sluggishly
or through slow emulation, and still others do not support
the full IEEE standard. Further, even if a device does
provide floating-point support, a developer may choose
to disable these floating-point capabilities for a given
order to support all of these different floating-point
scenarios, ScriptEase has a redefinable senumber
type which can be defined to whatever makes sense for
the system: standard double, smaller float, integer,
string, or even a structure or class pointer. All internal
numeric operations take place through macros, such as
instead of a+b,
so that the operation maps to the desired context.
results of numeric operations are then tailored to the
specific needs of the developer. Typically, device developers
without full floating-point hardware support will choose
an integer-only system, or a hybrid where integers are
used as much as possible. ScriptEase's use of senumber
and associated macro definitions make these choices
available without changing the underlying engine code.
Segmented Units. Certain devices need
to segment code to fit into 32K or 64K boundaries. The
ScriptEase engine and libraries have been designed to
be divisible into separate units to fit within these
Data Accommodations. Most devices have restrictions
on the use of global data. Global data may be available
only as read-only or, occasionally, not at all. The
ScriptEase engine is designed around macros and selectable
functions to accommodate either of these restrictions
where they apply.
Collection Flexibility. Garbage-collection has
proven itself to be the best-performing and most reliable
technique for managing high-level programming. In supporting
garbage-collection, the ScriptEase engine minimizes
the number of elements that need to be handled by the
garbage collector, while maximizing the speed of the
garbage collection process, saving both processing time
and minimizing memory use.
since there are situations when garbage collection is
not appropriate, such as when extra memory is not available
or when real-time restrictions dictate that garbage
collection can never run, no matter how quick it is.
Therefore, in these cases, a developer can build the
ScriptEase engine without garbage collection with a
single change of a compile-time option.
Lean, and Highly Mobile
inside of our ScriptEase engine is unmatched by any
other vendor on the market. Our pioneering techniques
use of ROM and RAM, while maximizing performance.
Providing compile-time configuration for processors,
language options, and build choices.
an API for adding wrappers that requires minimal code.
custom requirements for each individual device, including:
memory limitations, floating-point capabilities, segment
limits, global data, and real-time restrictions.
It's mean, lean, and highly mobile.