Nombas' Pioneering Techniques For Supporting ScriptEase Across Multiple Mobile Devices

A Complex Problem Domain

Developers 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.

On 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 code. Opening up the world of Device JavaScript to developers, ScriptEase Integrated SDK is unmatched by any other vendor in the marketplace.

Microsized, With Maximized Performance

Nombas couples a "microsized" footprint with high performance by using several innovative techniques:

Smart 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.

Compile-time 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 bytes.

"1-Line" 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.

Smart String Allocations. 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.

We 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 additional allocations.

Segmented 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.

Granular Compile-time Options. All ECMA libraries and many core JavaScript language capabilities can be selected 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.

Divergent Device Needs

The 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:

Centralized 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.

Memory 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:

• For Palm and other devices with small heap but larger long-term or database memory, memext can be mapped to a caching system.
  
  

• For EPOC devices that commonly need to compact memory frequently, memext can allow all but a few in-use items to move.

• For devices that distinguish read-only from writable memory, memext can use the type needed for the item in use.

• memext also handles situations in which memory limitations require overlaying of functions from disk.

• Finally, when memext is redefined for a particular device, the rest of the engine maps to optimized memory-handling code for that specific device.

Floating-point 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 application.

In 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 SE_FP_ADD(a,b) instead of a+b, so that the operation maps to the desired context.

The 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 boundaries.

Global 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.

Garbage 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.

However, 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.

Mean, Lean, and Highly Mobile

In summary, the capabilities of Device JavaScript wrapped inside of our ScriptEase engine is unmatched by any other vendor on the market. Our pioneering techniques include:

• Minimizing use of ROM and RAM, while maximizing performance.
  
  
• Providing compile-time configuration for processors, language options, and build choices.
  
  
• Providing an API for adding wrappers that requires minimal code.
  
  
• Supporting custom requirements for each individual device, including: memory limitations, floating-point capabilities, segment limits, global data, and real-time restrictions.

Device JavaScript…It's mean, lean, and highly mobile.