Subj : Re: newbie questions about porting JS to embedded processor
To   : netscape.public.mozilla.jseng
From : "Frederic Rudman" <frudman@ix.netcom.com>
Date : Tue Dec 09 2003 05:13 pm

Thank you very much for your very complete response. Please read my replies
interspersed within your points below.


> > 2) given the memory constaints, is this a reasonable project or does the
> > js compiler/vm require too much memory or cpu power?
.... (content removed for brevity)
> 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).

As for BSS, I always thought it meant "Block Static Storage": I like your
definition better!

As for the rest your answer, it seems to me that spidermonkey would be more
than a good fit for our purposes. Did I understand you correctly when you
say that it requires only 300 bytes of bss and less than 30k of rom for data
and less than 400k for program code? That's pretty low (and very good for me
if I understand this correctly).


>
> > 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?

There are many modern processors today that do not have an 8-bit byte!!! For
example, TI's TMS320Cxx DSP processors (and one that I'm using now) are
based on a 16-bit byte. That's great for many things, including char-based
and unicode-based software (for example, though that wasn't what TI's had in
mind) but it sucks when trying to port software that depends on 8-bit bytes!
(interpreters, for instance).



>
> > 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?

I mispoke about the malloc: I meant to say that it seems to me that
spidermonkey code might be ported easily enough given only basic .c library
functions such as malloc and not much else. Is that correct? (I do think I
saw even the printf family of fcns already implemented in the code)


> > 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?

I don't get it: I read on the mozilla site that v5.0 of JS is now "Rhino"
and that that is a Java-based implementation. What am I missing?


And one more question: based on my post on this newsgroup, someone emailed
me a note to consider www.nombas.com's ScriptEase software (an ECMA-based
version of Javascript). I spoke with one of their tech guys and it does
sound interesting (except for the price and the few number of devs
supporting it). Does anyone know anything about this or have any
recommendations (for or against)? I'm curious because ScriptEase seems to
run faster (at least on my machine) than a test I ran with jsshell (I
compiled the code from mozilla's cvs base)

Any comments would be very welcome.
Thanks to all,
Freddy.

.