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