Subj : Re: newbie questions about porting JS to embedded processor To : frudman@ix.netcom.com From : Brendan Eich Date : Tue Dec 09 2003 11:43 am frudman@ix.netcom.com wrote: > > 1) If this is not the correct group for this and other related > questions, pls advise as to which would be more appropriate (and ignore > the following questions :) You have the right group. > 2) given the memory constaints, is this a reasonable project or does the > js compiler/vm require too much memory or cpu power? It's a reasonable target. > Any ideas of the > approximate (normal/minimum) ram/rom footprint required for the compiled > runtime (not including actual scripts to be executed) in say the x86 > architecture (for comparison sake)? Are you using gcc? From bryner's -Os build, the output of the size(1) command: text data bss dec hex filename 410498 15284 304 426086 68066 libmozjs.so rodata and text can be in rom, if you can execute/fetch from rom without too much penalty. The readelf output is a little different: rodata 0x76d0 data 0x3110 text 0x4dca0 bss 0x130 The decimal conversions are rodata: 30416, data: 12560, text: 318624, and bss: 304, so it appears size is lumping other sections into text (probably size is combining at least rodata and text). Anyway, this ought to give you a picture of code and static data size (bss is the "blank starting storage", data that is zero-initialized by default, so not stored in object files). > 2a) the source code seemed to be fairly independent of the underlying > cpu architecture (except for the req of an 8-bit byte) Yeah, the days of the PDP-10 are gone. Or do you know of a modern CPU with other than 8-bit bytes? > and also > self-contained even to the degree of implementing its own malloc/str > fcns. Is this correct or am I reading the code wrong? Where do you see malloc implemented? Not in mozilla/js/src itself. Are you looking at NSPR? > 3) has anyone else (other ng or web site?) attempted to port > spidermonkey to an embedded platform? Succefully? What kind of > performance did you get? More than a few have done so successfully, but I have lost contact with them (scole, formerly @planetweb.com, may know more). I'll let others followup here. > 4) I realize that the current versions of JS have been moved over to > Java and the spidermonkey/c version is no longer the > latest-and-greatest. Not true. What gave you that idea? > But is it usable for my purposes and is it being > maintained (at least as far as bug reporting is concerned) It's certainly being maintained. It is the JS engine in all Mozilla products, and it's used all over the place, including in tellme.com's massively multi-threaded VXML service. SpiderMonkey (the modern codename for "JSRef") is featureful, with a rich API and numerous extensions (allowed) to the ECMA-262 spec. See http://lxr.mozilla.org/mozilla/source/js/src/jsconfig.h. If you want to use an ECMA-only mode, choose JS_VERSION_ECMA_3 as the value of the JS_VERSION macro. This will save some space, but the result won't be compatible with the maximum number of web pages. /be .