Small and embedded systems

Lars T Hansen lth at opera.com
Fri Jun 30 02:21:59 PDT 2006


A language is not designed in a vacuum -- it must take into account
the machines on which it will be used.  ECMAScript will be used
extensively not just in typical "desktop" systems but also in much
smaller "personal" systems, like set-top boxes, phones, PDAs,
in-flight entertainment systems, and the mythical web-enabled
refrigerator.  These two classes of systems are very different; I
thought I'd write a little about the latter.

Typical characteristics of many small systems are:

  - CPUs in the 100-400Mhz range (most of them at the low end)
  - small and poor caches (16KB write-through not unusual)
  - small and slow memories (4-8MB running at 1/10 CPU speed)
  - software floating-point
  - minimum-functionality operating systems
  - component cost extremely important

Obviously these systems will become a little larger over time, but for
the time being the low end is roughly constant.

(On a 100Mhz system one is probably happy to execute about 1000
ECMAScript bytecodes per millisecond, not taking into account effects
of software floating point, but that's another story.)

One of the reasons Opera is participating in the ECMAScript 4 process
is to ensure that the language is implementable on these systems -- we
do a lot of business in this space.  We do want the new language to
represent a substantial improvement to web authors, and we support it
wholeheartedly.  Yet it must not shut out a large fraction of the
systems that can currently run ECMAScript.  So we're looking for a
good compromise that will work well the next decade or so.

Our concerns are:

  - Fast on-line compilation must be possible -- ideally, a one-pass
    compiler that generates code without building and walking trees --
    the trees take too much space; walking them takes too much time.
    Page loading speed is usually more important than script execution
    speed, though that's changing a little with web applications.

  - "Expensive" features (usually expensive in memory use) must be
    strictly optional in the language, this applies particularly to
    reflection; even Function.prototype.toString is a hardship on the
    smallest systems.  Ideally we'd probably like to see such features
    left out completely unless they really pay their way.

  - Assumptions about device speeds and capabilities should be
    avoided.  I don't mind specifiying nanosecond precision for the
    clock, but nanosecond accuracy is another matter.

A clever implementation can do a lot, so it's hard to say whether
something is or is not possible to do in one pass or is or is not
expensive or system dependent.  But I urge some caution.

Not that I want to shut up debate on this list.  Please just be aware
that the target platform is not 2GHz systems with half a GB of memory
or better.

--lars





More information about the Es4-discuss mailing list