Subj : Re: newbie questions about porting JS to embedded processor To : Frederic Rudman From : Brendan Eich Date : Tue Dec 09 2003 04:42 pm Frederic Rudman wrote: >As for BSS, I always thought it meant "Block Static Storage": I like your >definition better! > > Hmm, maybe I'm too old and my memory has degraded. http://www.introl.com/introl-demo/AppNotes/sections/intro.html has "Blank Static Storage". "Block" doesn't really make sense. Anyone with deeper insight into the acronym's etymology, feel free to mail me! >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). > > You understand 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!!! > Sorry, I should have said "general purpose CPUs." DSP chips, I'm less familiar with (although I worked at MicroUnity, but that probably means nothing nowadays). > 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). > > Mozilla code is going to have some trouble there, I expect. Is there any compiler support to emulate 8-bit bytes for char and unsigned char? Overflow matters for much code that expects (uint8) casting to chop to 8 bits, e.g. >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) > > Yes, malloc is used universally, no sbrk or mmap. The engine's malloc and the API client's malloc must be the same, as usual. js/src/jsprf.c is a fork of old NSPR prprf.c code, to provide buffer-overrun-safe sprintf variants. >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? > > Can you point me to that document via a link? Thanks. >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). > Price matters, and independent of open source being "free", there's also the advantage that open source gives you greater flexibility in the long run, independent of any one company's fortunes. But having said all that, I wanted to add that I worked with NOMBAS folks in standardizing JS with ECMA, and they're fine people. If you like their product and can afford it, great. > 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) > > I would be interested in seeing that testcase. It's probably a synthetic benchmark. SpiderMonkey has not been optimized too much for such things (and optimizing for other than real-world workloads is fraught with hazards). It has been optimized for web pages, though, with more work yet to do. See http://bugzilla.mozilla.org, query for Browser product, JS Engine component, perf keyword. See http://bugzilla.mozilla.org/show_bug.cgi?id=61898 for a fairly old synthetic benchmark shootout between SpiderMonkey and ScriptEase. /be .