Subj : Re: newbie questions about porting JS to embedded processor To : netscape.public.mozilla.jseng From : "t o b e" Date : Tue Dec 09 2003 12:19 pm Hi Frederic, > 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 :) Seems as good a place as any. It's where I post all my questions (and where Brendan answers them :-) > 2) given the memory constaints, is this a reasonable project or does the > js compiler/vm require too much memory or cpu power? 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)? My own company's product is a javascript/flash enabled browser to run on Set-top boxes.. asking around we are able to (reasonably) easily run the Javascript enabled version in 16 Meg heap.. don't have any exact specs to hand but I will early next year when I actually measure all this. > 2a) the source code seemed to be fairly independent of the underlying > cpu architecture (except for the req of an 8-bit byte) 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? That's correct. Spidermonkey allocates from it's own heap (which you provide, of course). We've ported to a number of platforms with only a bare minimum of changes. > 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? See above. Performance is 'fine'. Obviously it depends of the speed of your underlying hardware but we get speeds that our users don't complain about. Spidermonkey certainly seems to have been written by competent engineers. It's efficient. > 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. But is it usable for my purposes and is it being > maintained (at least as far as bug reporting is concerned) It's usable for our purposes. .. > 5) Does anyone recommend a better js source to start for an embedded > port (rather than spider monkey) either because lighter or faster or > requiring fewer cpu/mem resources I don't. > Any other info to help me decide whether to go ahead with this or not > would be helpful and welcome. Make sure you know about GC roots. Be prepared to ask a few questions here and read the docs carefully because the examples are very brief. But apart from that it's all pretty much straightforward. t o b e .